On Thu, Nov 16, 2017 at 10:48 AM, Alex Bennée wrote:
> Getting rid of Mail::Address regressed behaviour with common
> get_maintainer scripts such as the Linux kernel. Fix the missed corner
> case and add a test for it.
It is not at all clear, based upon this text, what this is fixing.
When you re
gennady.kup...@gmail.com writes:
> Subject: Re: [PATCH 1/2] Simplify tracing code by removing trace key
> normalization concept
The usual style comment on the subject applies here.
> From: Gennady Kupava
>
> - to implement efficient traces with normalization, normalization
> implementation s
> git rebase [-i] [options] [--exec ] [--onto ] []
> []
> git rebase [-i] [options] [--exec ] [--onto ] --root []
> -git-rebase --continue | --abort | --skip | --edit-todo
> +git rebase --continue | --abort | --skip | --edit-todo
A good change.
> test -f "$apply_dir"/applying &&
> - die "
Hello again,
i see an error with v2.15.0 that happened already back in early
October (AlpineLinux [edge] pretty much up-to-date with newest git
but please don't ask exact version). I failed to reproduce it
back then, but now again, here is how.
- It seems related to having a hook (pre-commit), a
On Sat, Nov 18, 2017 at 1:04 PM, René Scharfe wrote:
> When showing function context it would be helpful to show comments
> immediately before declarations, as they are most likely relevant. Add
> a test for that.
>
> Signed-off-by: Rene Scharfe
> ---
> diff --git a/t/t4051-diff-function-context
Kaartic Sivaraam writes:
> $ GIT_EDITOR=gedit ./git commit --allow-empty
> Launched your editor, waiting...error: gedit died of signal 15
> error: There was a problem with the editor 'gedit'.
> Please supply the message using either -m or -F option.
>
> Though this is not something that's going t
On Sat, Nov 18, 2017 at 12:26 PM, Kaartic Sivaraam
wrote:
> Instead of hard-coding the offset strlen("refs/heads/") to skip
> the prefix "refs/heads/" use the skip_prefix() function which
> is more communicative and verifies that the string actually
> starts with that prefix.
>
> Though we don't c
"brian m. carlson" writes:
> This patch adds support for PATH, but it also removes the fixed paths.
> On many systems, unprivileged users don't have /usr/sbin in their PATH,
> and I know of no systems which provide /usr/lib as a PATH value.
> Therefore, it's possible that this change will break a
From: Gennady Kupava
- Do the check if the trace key is enabled sooner in call chain.
- Move just enough code from trace.c into trace.h header so all code
necessary to determine that trace is disabled could be inlined to
calling functions.
Signed-off-by: Gennady Kupava
---
trace.c | 3 +--
From: Gennady Kupava
- to implement efficient traces with normalization, normalization
implementation should be moved to header. as it seems better to not
overload header file with this normalization logic, suggestion is
just to remove it
- different macro exist specifically to handle trace
Currently 'git worktree add ', errors out when 'branch'
is not a local branch. It has no additional dwim'ing features that one
might expect.
Make it behave more like 'git checkout ' when the branch doesn't
exist locally, but a remote tracking branch uniquely matches the desired
branch name, i.e
Factor the functions out, so they can be re-used from other places. In
particular these functions will be re-used in builtin/worktree.c to make
git worktree add dwim more.
While there add some docs to the function.
Signed-off-by: Thomas Gummerer
---
Makefile | 1 +
builtin/checkout.
Sorry about the noise with v2 and v3 so quickly one after another. I
only too late realized that the new dwim for 'add '
doesn't make much sense if -b or --detach are given, and it's better
to keep on erroring out in these cases.
The previous rounds were at
https://public-inbox.org/git/20171112
Currently 'git worktree add ' creates a new branch named after the
basename of the , that matches the HEAD of whichever worktree we
were on when calling "git worktree add ".
Make 'git worktree add behave more like the dwim machinery in
'git checkout ', i.e. check if the new branch name uniquely
m
git archive -o name.tar.gz generates a gzipped file without needing an
explicit --format switch.
However, git archive -o name.tar.gz --remote [url] generates a tar
file, which is unexpected, bandwidth-heavier, and additionally in some
cases it's not immediately obvious that this has happened.
git
This extends git-send-email to also consider sendmail binaries in $PATH,
in addition to the (fixed) list of /usr/sbin and /usr/lib.fixed) list of
paths.
Signed-off-by: Florian Klink
---
Documentation/git-send-email.txt | 6 +++---
git-send-email.perl | 4 +++-
2 files changed, 6 ins
On 11/18, Thomas Gummerer wrote:
> Currently 'git worktree add ', errors out when 'branch'
> is not a local branch. It has no additional dwim'ing features that one
> might expect.
>
> Make it behave more like 'git checkout ' when the branch doesn't
> exist locally, but a remote tracking branch
This patch adds support for PATH, but it also removes the fixed paths.
On many systems, unprivileged users don't have /usr/sbin in their PATH,
and I know of no systems which provide /usr/lib as a PATH value.
Therefore, it's possible that this change will break automatic detection
of sendmail for m
On Sat, Nov 18, 2017 at 01:42:49PM +0100, Florian Klink wrote:
> This will search $PATH for a sendmail binary, instead of the (previously
> fixed) list of paths.
>
> Signed-off-by: Florian Klink
> ---
> Documentation/git-send-email.txt | 5 ++---
> git-send-email.perl | 3 ++-
> 2 f
On Tue, Nov 14, 2017 at 11:47 AM, Todd Zullinger wrote:
>
> Hi Shawn,
>
> Shawn Landden wrote:
>>
>> I think this is preferrable to bringing the assembly routines into the git
>> code-base, as a way of getting access to these high-performance routines to
>> a git available in Debian, Ubuntu, or
Am 18.11.2017 um 18:52 schrieb Jeff King:
> On Sat, Nov 18, 2017 at 11:20:04AM +0100, René Scharfe wrote:
>> Reported-by: Jeff King
>> Signed-off-by: Rene Scharfe
>
> I'm not sure I deserve a reported-by if I say "it looks fine" but am
> totally wrong. ;)
Right, wrong -- mere details. You poin
--
Cet e-mail sollicite strictement votre intérêt pour un partenariat avec
moi pour un investissement énorme, répondez pour plus de détails.
Cordialement,
Khvostova Zhanna
Non-empty lines before a function definition are most likely comments
for that function and thus relevant. Include them in function context.
Such a non-empty line might also belong to the preceding function if
there is no separating blank line. Stop extending the context upwards
also at the next
On 11/15, Thomas Gummerer wrote:
> On 11/14, Eric Sunshine wrote:
> > On Tue, Nov 14, 2017 at 3:14 PM, Eric Sunshine
> > wrote:
> > > For my own edification...
> > > [...]
> > > git worktree add ../topic
> > >
> > > * Correctly errors out, refusing to create a new branch named "topic",
> > > if "
The check for function context (-W) together with user-defined function
line patterns reuses hello.c and pretends it's written in a language in
which function lines contain either "printf" or a trailing curly brace.
That's a bit obscure.
Make the test easier to read by adding a small PowerShell sc
Add a helper for checking if a given record is a function line. It
frees callers from having to deal with the buffer arguments of
match_func_rec().
Signed-off-by: Rene Scharfe
---
xdiff/xemit.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/xdiff/xemit.c b/xdiff/
Currently 'git worktree add ', errors out when 'branch'
is not a local branch. It has no additional dwim'ing features that one
might expect.
Make it behave more like 'git checkout ' when the branch doesn't
exist locally, but a remote tracking branch uniquely matches the desired
branch name, i.e
Factor the functions out, so they can be re-used from other places. In
particular these functions will be re-used in builtin/worktree.c to make
git worktree add dwim more.
While there add some docs to the function.
Signed-off-by: Thomas Gummerer
---
The previous round of this series is at
https
Currently 'git worktree add ' creates a new branch named after the
basename of the , that matches the HEAD of whichever worktree we
were on when calling "git worktree add ".
Make 'git worktree add behave more like the dwim machinery in
'git checkout ', i.e. check if the new branch name uniquely
m
Function context can be bigger than -A/-B/-C context. To find the
beginning of the combined context we search backwards. Currently we
check at each loop iteration what we're looking for and determine the
effective upper boundary based on that.
Simplify this a bit by setting the variable "from" t
Non-empty lines before a function definition are most likely comments
for that function and thus relevant. Include them in function context.
Such a non-empty line might also belong to the preceeding function if
there is no separating blank line. Stop extending the context upwards
also at the nex
When showing function context it would be helpful to show comments
immediately before declarations, as they are most likely relevant. Add
a test for that.
Signed-off-by: Rene Scharfe
---
t/t4051-diff-function-context.sh | 4
t/t4051/hello.c | 3 +++
2 files changed, 7 inse
The option -W/--function-context lets git diff and git grep show the
whole surrounding function as context. For the sake of simplicity and
performance they don't fully parse the files, but as a heuristic show
all lines from the preceding function line to the next one.
This series refines that heu
On Sat, Nov 18, 2017 at 11:20:04AM +0100, René Scharfe wrote:
> Am 17.11.2017 um 23:06 schrieb Jeff King:
> > There's one more case in write_section() that uses "==". That's not
> > actually wrong, but I wonder if we'd want to make it "< 0" for
> > consistency.
>
> Actually it *is* wrong.
Thanks
On Thursday 16 November 2017 11:34 AM, Junio C Hamano wrote:
* I tried this with "emacsclient" but it turns out that Emacs folks
have already thought about this issue, and the program says
"Waiting for Emacs..." while it does its thing, so from that
point of view, perhaps as Stefan
The documentation for 'create_branch()' was incomplete as it didn't say
what certain parameters were used for. Further a parameter name wasn't
very communicative.
So, add missing documentation for the sake of completeness and easy
reference. Also, rename the concerned parameter to make its name mo
When a user tries to rename a branch that has a "bad name" (e.g.,
starts with a '-') then we warn them that the misnamed branch has
been renamed "away". A similar message is shown when trying to create
a copy of a misnamed branch even though it doesn't remove the misnamed
branch. This is not correc
Instead of hard-coding the offset strlen("refs/heads/") to skip
the prefix "refs/heads/" use the skip_prefix() function which
is more communicative and verifies that the string actually
starts with that prefix.
Though we don't check for the result of verification here as
it's (almost) always the c
39bd6f726 (Allow checkout -B to update the current
branch, 2011-11-26) added 'clobber_head' (now, 'clobber_head_ok')
"before" 'track' as 'track' was closely related 'clobber_head' for
the purpose the commit wanted to achieve. Looking from the perspective
of how the arguments are used it turns out
On the process of making 'git' give more useful error messages
when trying to rename a branch[0], I found a few things that could
be cleaned up. After noticing that the cleanup commits exceeded
the commits that are related to the series, I thought it would
be better to separate the cleanups into an
Signed-off-by: Kaartic Sivaraam
---
git-rebase.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index 6344e8d5e..42a485aaa 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -9,7 +9,7 @@ OPTIONS_STUCKLONG=t
OPTIONS_SPEC="\
git rebase [-i] [
On 18/11/17 03:57, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Phillip Wood writes:
>>
>>> From: Phillip Wood
>>>
>>> I've updated these based on the feedback for v2. I've dropped the
>>> patch that stopped print_commit_summary() from dying as I think it is
>>> better to die than return
This will search $PATH for a sendmail binary, instead of the (previously
fixed) list of paths.
Signed-off-by: Florian Klink
---
Documentation/git-send-email.txt | 5 ++---
git-send-email.perl | 3 ++-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-s
小川恭史 writes:
> I upgraded the version of git from 2.13.1 to 2.15.0 on Mac and fixed my issue.
> Thanks.
Ah, yes, that bug was fixed in the 2.14.0 timeframe but was
backported to 2.13.2 and onwards (it was a bug in 2.13.0, I think).
On 18/11/17 03:57, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Phillip Wood writes:
>>
>>> From: Phillip Wood
>>>
>>> I've updated these based on the feedback for v2. I've dropped the
>>> patch that stopped print_commit_summary() from dying as I think it is
>>> better to die than return
On 17/11/17 22:06, Jeff King wrote:
> On Wed, Nov 15, 2017 at 12:40:43PM +, Phillip Wood wrote:
>
>> From: Phillip Wood
>>
>> As explained in commit 06f46f237 (avoid "write_in_full(fd, buf, len)
>> != len" pattern, 2017–09–13) the return value of write_in_full() is
>> either -1 or the request
Am 17.11.2017 um 23:06 schrieb Jeff King:
> There's one more case in write_section() that uses "==". That's not
> actually wrong, but I wonder if we'd want to make it "< 0" for
> consistency.
Actually it *is* wrong.
-- >8 --
Subject: [PATCH] config: flip return value of write_section()
d9bd4cbb9
I upgraded the version of git from 2.13.1 to 2.15.0 on Mac and fixed my issue.
Thanks.
2017-11-18 16:56 GMT+09:00 Junio C Hamano :
> 小川恭史 writes:
>
>>> Please make it a habit (not limited to when interacting with
>>> _this_ project) to state a bit more than "does not work";
>>> instead, say "it i
Am 17.11.2017 um 23:33 schrieb Jeff King:
On Mon, Nov 06, 2017 at 05:13:15PM +0100, Simon Ruderich wrote:
On Sat, Nov 04, 2017 at 10:07:00PM -0400, Jeff King wrote:
Yes, I think what you've written here (and below) is quite close to the
error_context patches I linked elsewhere in the thread. In
Good day dear, i hope this mail meets you well? my name is Jack, from the U.S.
I know this may seem inappropriate so i ask for your forgiveness but i wish to
get to know you better, if I may be so bold. I consider myself an easy-going
man, adventurous, honest and fun loving person but I am curre
--
I am Mrs Nicole i have a pending project of fulfillment to put in your
hand, i will need your support to make this ream come through, could
you le me know your interest to enable me give you further information,
and I hereby advice that you send the below mentioned information
I decided
51 matches
Mail list logo
