On 01/24/2017 08:15 AM, Johannes Sixt wrote:
> If at all possible, please use your real email address as the From
> address. It is pointless to hide behind a fake address because as Git
> contributor you will have to reveal your identity anyway.
These are both real addresses, but for send-mail I w
> On 23 Jan 2017, at 20:38, Junio C Hamano wrote:
>
> Junio C Hamano writes:
>
>> So you are worried about the case where somebody on a case
>> insensitive but case preserving system would do
>>
>> $ edit file.txt
>> $ edit .gitattributes
>> $ git add file.txt .gitattributes
>>
>> and
On Fri, Jan 20, 2017 at 10:16:31AM -0800, Junio C Hamano wrote:
> Stefan Hajnoczi writes:
>
> > v2.9.3::Makefile may convey that the user originally provided v2.9.3:
> > but is that actually useful information?
>
> You are either asking a wrong question, or asking a wrong person
> (i.e. Git) the
On Fri, Jan 20, 2017 at 02:56:26PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > It's not ignored; just as with git-log, it's a pathspec to limit the
> > diff. E.g.:
> >
> > $ git show --name-status v2.9.3
> > ...
> > M Documentation/RelNotes/2.9.3.txt
> > M Documenta
> On 24 Jan 2017, at 01:18, Junio C Hamano wrote:
>
> * jk/fsck-connectivity-check-fix (2017-01-17) 6 commits
> (merged to 'next' on 2017-01-23 at e8e9b76b84)
> + fsck: check HAS_OBJ more consistently
> + fsck: do not fallback "git fsck " to "git fsck"
> + fsck: tighten error-checks of "git fsc
Hi Thomas,
On Sat, 21 Jan 2017, Thomas Gummerer wrote:
> This is the first try to implement the RFC I posted a week ago [1]. It
> introduces a new push verb for git stash. I couldn't come up with
> any better name that wasn't already taken. If anyone has ideas I'd be
> very happy to hear them.
Dear Sir/Madam.
Assalamu`Alaikum.
I am Dr mohammad ouattara, I have ($10.6 Million us dollars) to transfer into
your account,
I will send you more details about this deal and the procedures to follow when
I receive a positive response from you,
Have a great day,
Dr mohammad ouattara.
Hi Matthieu,
On Mon, 23 Jan 2017, Matthieu Moy wrote:
> * Who's willing to mentor?
As in the years before, I am willing to mentor.
Ciao,
Johannes
On Mon, Jan 23, 2017 at 11:53:43AM -0800, Junio C Hamano wrote:
> Patrick Steinhardt writes:
>
> > This patch is mostly a request for comments. The use case is to
> > be able to configure an HTTP proxy for all subdomains of a
> > certain domain where there are hundreds of subdomains. The most
> >
Hey Junio,
On Tue, Jan 24, 2017 at 12:06 AM, Junio C Hamano wrote:
> Pranit Bauva writes:
>
>> We can probably make it useful with some extended efforts. I use
>> git-blame and I sometimes find that I don't need things like the name
>> of the author, time, timezone and not even the file name and
Hi Peff,
On Mon, 23 Jan 2017, Jeff King wrote:
> Is there any interest in people adding the ISO qsort_s() to their libc
> implementations? It seems like it's been a fair number of years by now.
Visual C supports it *at least* since Visual Studio 2005:
https://msdn.microsoft.com/en-us/library/4x
On Tue, Jan 24, 2017 at 11:04:21AM +0100, Lars Schneider wrote:
> "fsck: prepare dummy objects for --connectivity-check" seems to
> make t1450-fsck.sh fail on macOS with TravisCI:
>
> Initialized empty Git repository in /Users/travis/build/git/git/t/trash
> directory.t1450-fsck/connectivity-only
On Tue, Jan 24, 2017 at 12:28 PM, Johannes Schindelin
wrote:
> Hi Matthieu,
>
> On Mon, 23 Jan 2017, Matthieu Moy wrote:
>
>> * Who's willing to mentor?
>
> As in the years before, I am willing to mentor.
I am also willing to mentor.
Thanks!
On Tue, Jan 24, 2017 at 12:44:10PM +0100, Johannes Schindelin wrote:
> Hi Peff,
>
> On Mon, 23 Jan 2017, Jeff King wrote:
>
> > Is there any interest in people adding the ISO qsort_s() to their libc
> > implementations? It seems like it's been a fair number of years by now.
>
> Visual C support
mn Sat, Jan 21, 2017 at 09:26:08PM -0800, David Aguilar wrote:
> > > An obvious second
> > > best option would be to drop -Wall from the "everybody" CFLAGS and
> > > move it to DEVELOPER_CFLAGS instead.
> >
> > Yeah, though that doesn't help the example above.
> >
> > As ugly as warning("%s", ""
> On 24 Jan 2017, at 14:27, Jeff King wrote:
>
> On Tue, Jan 24, 2017 at 11:04:21AM +0100, Lars Schneider wrote:
>
>> "fsck: prepare dummy objects for --connectivity-check" seems to
>> make t1450-fsck.sh fail on macOS with TravisCI:
>>
>> Initialized empty Git repository in /Users/travis/build
Signed-off-by: Patrick Steinhardt
---
.mailmap | 1 +
1 file changed, 1 insertion(+)
diff --git a/.mailmap b/.mailmap
index 9c87a3840..ea59205b9 100644
--- a/.mailmap
+++ b/.mailmap
@@ -177,6 +177,7 @@ Paolo Bonzini
Pascal Obry
Pascal Obry
Pat Notz
+Patrick Steinhardt
Paul Mackerra
Hi,
This is version two of my patch series.
The use case is to be able to configure an HTTP proxy for all
subdomains of a domain where there are hundreds of subdomains.
Previously, I have been using complete regular expressions with
an escape-mechanism to match the configuration key's URLs.
Acco
The URL matching function computes for two URLs whether they match not.
The match is performed by splitting up the URL into different parts and
then doing an exact comparison with the to-be-matched URL.
The main user of `urlmatch` is the configuration subsystem. It allows to
set certain configurat
The `url_normalize` function is used to validate and normalize URLs. As
such, it does not allow for some special characters to be part of the
URLs that are to be normalized. As we want to allow using globs in some
configuration keys making use of URLs, namely `http..`, but
still normalize them, we
The `url_info` structure contains information about a normalized URL
with the URL's components being represented by different fields. The
host and port part though are to be accessed by the same `host` field,
so that getting the host and/or port separately becomes more involved
than really necessar
On Tue, Jan 24, 2017 at 1:54 AM Stefan Hajnoczi wrote:
> > The use of "git show" you are demonstrating is still about showing
> > the commit object, whose behaviour is defined to show the log
> > message and the diff relative to its sole parent, limited to the
> > paths that match the pathspec.
>
I noticed some weird spacing when comparing files with git diff
--color-words. The space before a colored word disappears sometimes.
$ git --version
git version 2.11.0.485.g4e59582ff
echo "FOO foo; foo = bar" > a
echo "FOO foo = baz" > b
git diff --color-words --no-index a b
FOOfoo; foo = barbaz
From: "Patrick Steinhardt"
a quick comment on the documentation part ..
The URL matching function computes for two URLs whether they match not.
The match is performed by splitting up the URL into different parts and
then doing an exact comparison with the to-be-matched URL.
The main user of `
Am 23.01.2017 um 20:07 schrieb Junio C Hamano:
> René Scharfe writes:
>
>> Implement qsort_s() as a wrapper to the GNU version of qsort_r(1) and
>> use it on Linux. Performance increases slightly:
>>
>> Test HEAD^ HEAD
>> --
Am 24.01.2017 um 00:54 schrieb Jeff King:
The speed looks like a reasonable outcome. I'm torn on the qsort_r()
demo patch. I don't think it looks too bad. OTOH, I don't think I would
want to deal with the opposite-argument-order versions.
The code itself may look OK, but it's not really necessa
On Sat, Jan 21, 2017 at 7:53 AM, Brian J. Davis wrote:
>
> On 1/19/2017 7:22 PM, Stefan Beller wrote:
Between the init and the update step you can modify the URLs.
These commands are just a repetition from the first email, but the
git commands can be viewed as moving from one s
> Junio C Hamano hat am 20. Januar 2017 um 00:37
> geschrieben:
[snip]
> * rh/mergetool-regression-fix (2017-01-10) 14 commits
> (merged to 'next' on 2017-01-10 at e8e00c798b)
> + mergetool: fix running in subdir when rerere enabled
> + mergetool: take the "-O" out of $orderfile
> + t7610
W dniu 23.01.2017 o 14:15, Stefan Hajnoczi pisze:
> On Fri, Jan 20, 2017 at 10:16:31AM -0800, Junio C Hamano wrote:
>> My only piece of advice to folks who feel that way is to learn Git
>> more and get comfortable. You can do neat things like
>>
>>$ git grep -e pattern rev -- t ':!t/helper/'
W dniu 21.01.2017 o 21:08, Thomas Gummerer pisze:
> Don't mention git reset --hard in the documentation for git stash save.
> It's an implementation detail that doesn't matter to the end user and
> thus shouldn't be exposed to them.
>
> Signed-off-by: Thomas Gummerer
> ---
> Documentation/git-st
On Sat, Jan 21, 2017 at 08:08:02PM +, Thomas Gummerer wrote:
> diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
> index 2e9cef06e6..0ad5335a3e 100644
> --- a/Documentation/git-stash.txt
> +++ b/Documentation/git-stash.txt
> @@ -47,8 +47,9 @@ OPTIONS
>
> save [-p|--patc
On 24/01/17 00:46, Jeff King wrote:
> This is similar to many of our uses of sha1-array, but it
> overcomes one limitation of a sha1-array: when you are
> de-duplicating a large input with relatively few unique
> entries, sha1-array uses 20 bytes per non-unique entry.
> Whereas this set will use
On Tue, Jan 24, 2017 at 08:26:40PM +, Ramsay Jones wrote:
> > +++ b/oidset.c
> > @@ -0,0 +1,49 @@
> > +#include "cache.h"
> > +#include "oidset.h"
> > +
> > +struct oidset_entry {
> > + struct hashmap_entry hash;
> > + struct object_id oid;
> > +};
> > +
> > +int oidset_hashcmp(const void
On Tue, Jan 24, 2017 at 07:00:03PM +0100, René Scharfe wrote:
> > I do worry about having to support more implementations in the
> > future that have different function signature for the comparison
> > callbacks, which will make things ugly, but this addition alone
> > doesn't look too bad to me.
On Tue, Jan 24, 2017 at 07:00:07PM +0100, René Scharfe wrote:
> Am 24.01.2017 um 00:54 schrieb Jeff King:
> > The speed looks like a reasonable outcome. I'm torn on the qsort_r()
> > demo patch. I don't think it looks too bad. OTOH, I don't think I would
> > want to deal with the opposite-argument
From: "Jakub Narębski"
W dniu 23.01.2017 o 14:15, Stefan Hajnoczi pisze:
On Fri, Jan 20, 2017 at 10:16:31AM -0800, Junio C Hamano wrote:
My only piece of advice to folks who feel that way is to learn Git
more and get comfortable. You can do neat things like
$ git grep -e pattern rev --
Consider having a submodule 'sub' and a nested submodule at 'sub/nested'.
When nested is already absorbed into sub, but sub is not absorbed into
its superproject, then we need to fixup the gitfile and core.worktree
setting for 'nested' when absorbing 'sub', but we do not need to move
its git dir ar
Jeff King writes:
>> > As ugly as warning("%s", "") is, I think it may be the thing that annoys
>> > the smallest number of people.
>> >
>> > -Peff
>>
>> How about using warning(" ") instead?
>>
>> For difftool.c specifically, the following is a fine solution,
>> and doesn't require that we ch
On 01/24, Stefan Beller wrote:
> + if (read_gitfile_gently(old_git_dir, &err_code) ||
> + err_code == READ_GITFILE_ERR_NOT_A_REPO) {
> + /*
> + * If it is an actual gitfile, it doesn't need migration,
> + * however in case of a recursively nested su
Thomas Braun writes:
>> * rh/mergetool-regression-fix (2017-01-10) 14 commits
>> (merged to 'next' on 2017-01-10 at e8e00c798b)
>> + mergetool: fix running in subdir when rerere enabled
>> + mergetool: take the "-O" out of $orderfile
>> + t7610: add test case for rerere+mergetool+subdir bug
On 01/24, Stefan Beller wrote:
> On Tue, Jan 24, 2017 at 1:58 PM, Brandon Williams wrote:
> > On 01/24, Stefan Beller wrote:
> >> + if (read_gitfile_gently(old_git_dir, &err_code) ||
> >> + err_code == READ_GITFILE_ERR_NOT_A_REPO) {
> >> + /*
> >> + * If it is
On Tue, Jan 24, 2017 at 1:58 PM, Brandon Williams wrote:
> On 01/24, Stefan Beller wrote:
>> + if (read_gitfile_gently(old_git_dir, &err_code) ||
>> + err_code == READ_GITFILE_ERR_NOT_A_REPO) {
>> + /*
>> + * If it is an actual gitfile, it doesn't need migratio
On Tue, Jan 24, 2017 at 01:52:13PM -0800, Junio C Hamano wrote:
> > I dunno. As ugly as the "%s" thing is in the source, at least it doesn't
> > change the output. Not that an extra space is the end of the world, but
> > it seems like it's letting the problem escape from the source code.
> >
> > D
Cornelius Weig writes:
>> Please study item (5) "Sign your work" in
>> Documentation/SubmittingPatches and sign off your work.
>
> I followed the recommendations to submitting work, and in the first
> round signing is discouraged.
Just this point. You found a bug in our documentation if that is
On 01/25/2017 12:24 AM, Junio C Hamano wrote:
> Cornelius Weig writes:
>
>>> Please study item (5) "Sign your work" in
>>> Documentation/SubmittingPatches and sign off your work.
>>
>> I followed the recommendations to submitting work, and in the first
>> round signing is discouraged.
>
> Just t
On Tue, Jan 24, 2017 at 3:33 PM, Cornelius Weig
wrote:
> On 01/25/2017 12:24 AM, Junio C Hamano wrote:
>> Cornelius Weig writes:
>>
Please study item (5) "Sign your work" in
Documentation/SubmittingPatches and sign off your work.
>>>
>>> I followed the recommendations to submitting work
In this second iteration, only absorb_git_dir_into_superproject is touched,
which does the check if connect_work_tree_and_git_dir is needed.
Internally I also had a patch that converts is_submodule_populated
to be gentle, but it is not needed here, so I dropped it before sending out.
Thanks,
Stef
Consider having a submodule 'sub' and a nested submodule at 'sub/nested'.
When nested is already absorbed into sub, but sub is not absorbed into
its superproject, then we need to fixup the gitfile and core.worktree
setting for 'nested' when absorbing 'sub', but we do not need to move
its git dir ar
In a later patch we want to react to only a subset of errors, defaulting
the rest to die as usual. Separate the block that takes care of dying
into its own function so we have easy access to it.
Signed-off-by: Stefan Beller
---
cache.h | 1 +
setup.c | 48 ++-
This follows a93bedada (setup: add gentle version of read_gitfile,
2015-06-09), and assumes the same reasoning. resolve_git_dir is unsuited
for speculative calls, so we want to use the gentle version to find out
about potential errors.
Signed-off-by: Stefan Beller
---
cache.h | 4 +++-
setup.c |
From: Cornelius Weig
Git does not create a history for tags, in contrast to common
expectation to simply version everything. This can be changed by using
the `--create-reflog` flag when creating the tag. However, a config
option to enable this behavior by default is missing.
This commit adds the
>
>> Do not PGP sign your patch, at least *for now*. (...)
>
And maybe these 2 small words are the bug in the documentation?
Shall we drop the "at least for now" part, like so:
---8<---
>From 2c4fe0e67451892186ff6257b20c53e088c9ec67 Mon Sep 17 00:00:00 2001
From: Stefan Beller
Date: Tue, 24 Jan
On 01/25/2017 12:43 AM, Stefan Beller wrote:
> On Tue, Jan 24, 2017 at 3:33 PM, Cornelius Weig
> wrote:
>> On 01/25/2017 12:24 AM, Junio C Hamano wrote:
>>> Cornelius Weig writes:
>>>
> Please study item (5) "Sign your work" in
> Documentation/SubmittingPatches and sign off your work.
>
On 01/25/2017 01:21 AM, Stefan Beller wrote:
>>
>>> Do not PGP sign your patch, at least *for now*. (...)
>>
>
> And maybe these 2 small words are the bug in the documentation?
> Shall we drop the "at least for now" part, like so:
>
> ---8<---
> From 2c4fe0e67451892186ff6257b20c53e088c9ec67 Mon S
On 01/24, Stefan Beller wrote:
> Consider having a submodule 'sub' and a nested submodule at 'sub/nested'.
> When nested is already absorbed into sub, but sub is not absorbed into
> its superproject, then we need to fixup the gitfile and core.worktree
> setting for 'nested' when absorbing 'sub', bu
On Tue, Jan 24, 2017 at 4:43 PM, Cornelius Weig
wrote:
> -(5) Sign your work
> +(5) Certify your work by signing off.
That sounds better than what I proposed.
Thanks,
Stefan
On Tue, Jan 24, 2017 at 4:21 PM, Stefan Beller wrote:
>
> +Do not PGP sign your patch. Most likely, your maintainer or other
> +people on the list would not have your PGP key and would not bother
> +obtaining it anyway.
I think even that could be further simplified - by just removing all
comments
Linus Torvalds wrote:
> On Tue, Jan 24, 2017 at 4:21 PM, Stefan Beller wrote:
> >
> > +Do not PGP sign your patch. Most likely, your maintainer or other
> > +people on the list would not have your PGP key and would not bother
> > +obtaining it anyway.
>
> I think even that could be further simpl
On 2017-01-23 04:09:17, brian m. carlson wrote:
> On Mon, Jan 23, 2017 at 03:57:13AM +0100, Øyvind A. Holm wrote:
> > On 2017-01-22 02:41:56, brian m. carlson wrote:
> > > While Git has traditionally built its documentation using
> > > AsciiDoc, some people wish to use Asciidoctor for speed or oth
When e.g. signing a tag fails, the user is left with the following
output on their console:
error: gpg failed to sign the data
error: unable to sign the tag
There is no indication of what specifically failed, and no indication
how they might solve the problem.
It turns out, gpg still does out
Hey Cornelius,
On Wed, Jan 25, 2017 at 5:49 AM, wrote:
> From: Cornelius Weig
>
> Git does not create a history for tags, in contrast to common
> expectation to simply version everything. This can be changed by using
> the `--create-reflog` flag when creating the tag. However, a config
> option
To avoid taking up so much space on normal output printing duplicate
information on consecutive lines that "belong" to the same revision,
this option allows to print a single line with the information about
the revision before the lines of content themselves.
Signed-off-by: Edmundo Carmona Antoran
Revision information will be highlighted so that it's easier
to tell from content of the file being "blamed".
Signed-off-by: Edmundo Carmona Antoranz
---
Documentation/blame-options.txt | 5 +
Documentation/git-blame.txt | 2 +-
builtin/blame.c | 13 +
3 fil
When printing aggregate information about revisions, this option
allows to add the 1-line summary of the revision to provide the
reader with some additional context about the revision itself.
Signed-off-by: Edmundo Carmona Antoranz
---
Documentation/blame-options.txt | 4
Documentation/git
From: "Stefan Beller"
Do not PGP sign your patch, at least *for now*. (...)
And maybe these 2 small words are the bug in the documentation?
Shall we drop the "at least for now" part, like so:
---8<---
From 2c4fe0e67451892186ff6257b20c53e088c9ec67 Mon Sep 17 00:00:00 2001
From: Stefan Bell
On 1/24/2017 12:49 PM, Stefan Beller wrote:
On Sat, Jan 21, 2017 at 7:53 AM, Brian J. Davis wrote:
On 1/19/2017 7:22 PM, Stefan Beller wrote:
Between the init and the update step you can modify the URLs.
These commands are just a repetition from the first email, but the
git commands can be v
66 matches
Mail list logo
