On Sun, Jan 31, 2016 at 12:01:44AM +, Eric Wong wrote:
> > > --- a/builtin/clone.c
> > > +++ b/builtin/clone.c
> > > @@ -47,6 +47,7 @@ static const char *real_git_dir;
> > > static char *option_upload_pack = "git-upload-pack";
> > > static int option_verbosity;
> > > static int option_progr
From: Will Palmer
To name a commit, you can now use the :/!- regex
style, and consequentially, say
$ git rev-parse HEAD^{/!-foo}
and it will return the hash of the first commit reachable from HEAD,
whose commit message does not contain "foo". This is the opposite of the
existing ^{/} syntax
Torsten Bögershausen wrote:
> On 2016-01-30 14.13, Eric Wong wrote:
> > The ssh(1) command has an equivalent switches which we may
> > pass when we run them.
> Should we mention that putty and tortoiseplink don't have these options ?
> At least in the commit message ?
Sure, will remember for v2
On 2016-01-30 14.13, Eric Wong wrote:
Nicely done, some minor questions inline.
> Sometimes, it is necessary to force IPv4-only or IPv6-only
> operation on networks where name lookups may return a
> non-routable address and stall remote operations.
>
> The ssh(1) command has an equivalent switches
On 01/30/2016 03:30 PM, Moritz Neeb wrote:
> Currently I am working on replacing strbuf_getline_lf() by
> strbuf_getline() in places where the input is trimmed immediately after
> reading, cf. $gmane/284104, "Notes on the remaining strbuf_getline_lf()
> callers", 2nd point.
This thread turned obso
On Tue, Jan 26, 2016 at 06:44:44PM +0700, Nguyễn Thái Ngọc Duy wrote:
> This new option allows the user to write to or read from
> .git/common/config in worktree v1. In worktree v0, --repo is an alias
> of --local.
Looks like by default a value is always set in a local
config, which might be dange
When a server supports hook options, we send it options for quiet and
force if the user used push --force/--quiet.
Signed-off-by: Dennis Kaarsemaker
---
send-pack.c | 10 ++
t/t5544-push-hook-options.sh | 37 +
2 files changed, 47 inse
Allow the client to specify options to influence the behaviour of hooks
run by receive-pack. This can be used to e.g. tell hooks to be quiet or
verbose, or to ignore errors.
These options are passed on to the hooks in the environment variable
GIT_HOOK_OPTIONS, which hooks can choose to respect to
We'll need it in the next patch.
Signed-off-by: Dennis Kaarsemaker
---
connect.c | 3 +--
connect.h | 1 +
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/connect.c b/connect.c
index fd7ffe1..9e64b0b 100644
--- a/connect.c
+++ b/connect.c
@@ -12,7 +12,6 @@
#include "transport.h"
I have a few pre-receive hooks that are meant to catch mistakes. They are
fairly strict, as the mistakes it catches can have some serious bad effects.
However, sometimes they get it wrong (and can't really get it right) and it
would be really useful to override them.
Currently I do this by parsein
The input that is read is trimmed with strbuf_trim() immediately.
There is thus no logic expecting CR, so strbuf_getline_lf() can be
replaced by its CRLF counterpart.
Signed-off-by: Moritz Neeb
---
builtin/clean.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --gi
The notes that are copied from stdin are trimmed with strbuf_rtrim()
after splitting by ' '. There is thus no logic expecting CR, so
strbuf_getline_lf() can be replaced by its CRLF counterpart.
Signed-off-by: Moritz Neeb
---
builtin/notes.c | 2 +-
1 file changed, 1 insertion(+), 1 d
In read_rebase_todolist() every line is, after reading, checked
for a comment_line_char. After that it is trimmed via strbuf_trim().
Assuming we do never expect a CR as comment_line_char,
strbuf_getline_lf() can be safely replaced by its CRLF counterpart.
Signed-off-by: Moritz Neeb
The line read from the branch file is directly trimmed after
reading with strbuf_trim(). There is thus no logic expecting CR,
so strbuf_getline_lf() can be replaced by its CRLF counterpart.
Signed-off-by: Moritz Neeb
---
remote.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
The lines read from BISECT_NAMES are trimmed with strbuf_trim()
immediately. There is thus no logic expecting CR, so
strbuf_getline_lf() can be replaced by its CRLF counterpart.
Signed-off-by: Moritz Neeb
---
bisect.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
This series deals with strbuf_getline_lf() in certain codepaths:
Those, where the input that is read, is trimmed before doing anything that
could possibly expect a CR character. As the codepath after trimming can not
in any way expect a CR at the end of the line, because trim dropped it before
the
On Fri, Jan 29, 2016 at 10:55:52AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > The end result is roughly the same, but it's a lot less churn, and it's
> > more likely for new callers to get it right, because they have to go the
> > extra mile to ignore the error. I say "roughly" becaus
On Tue, Jan 26, 2016 at 06:44:41PM +0700, Nguyễn Thái Ngọc Duy wrote:
> Worktree v1 may have different .git file split than v0. Add support
> code to change common file list based on extensions.worktree. The list
> for now is identical to v0.
In the end this turned out to be needed only for "commo
Currently I am working on replacing strbuf_getline_lf() by
strbuf_getline() in places where the input is trimmed immediately after
reading, cf. $gmane/284104, "Notes on the remaining strbuf_getline_lf()
callers", 2nd point.
One instance I found was in wt-status.c. In read_rebase_todolist() the
lin
On Wed, Jan 27, 2016 at 02:12:52PM -0800, Junio C Hamano wrote:
> More seriously, are we confident that the overall worktree support
> is mature enough by now that once we add an experimental feature X
> at version 1, we can promise to keep maintaining it forever at
> version N for any positive int
On Tue, Jan 26, 2016 at 06:44:40PM +0700, Nguyễn Thái Ngọc Duy wrote:
> +WORKTREE VERSIONS AND MIGRATION
> +---
> +Multiple worktree is still an experimental feature and evolving. Every
> +time the behavior is changed, the "worktree version" is stepped
> +up. Worktree ve
> You can use custom cat-file formatting to output your "name" strings as
> part of the same field. IOW, something like:
[...]
> If you're really going to do a lot of interactive back-and-forth access
> of objects, though, I think you want to set up pipes to cat-file.
OMG, I didn't realize that ca
Eric Wong wrote:
> rsync support is untouched for now since it is deprecated
> and scheduled to be removed.
I forgot add I'm not sure how to actually go about testing these changes
automatically since they involve DNS setups. And the test suite seems
really slow nowadays, I guess/hope our test c
Sometimes, it is necessary to force IPv4-only or IPv6-only
operation on networks where name lookups may return a
non-routable address and stall remote operations.
The ssh(1) command has an equivalent switches which we may
pass when we run them.
rsync support is untouched for now since it is depre
Junio C Hamano wrote:
> Eric Wong writes:
>
> > getaddrinfo() may return multiple addresses, not all of which
> > are equally performant. In some cases, a user behind a non-IPv6
> > capable network may get an IPv6 address which stalls connect().
>
> I'd assume that you are not solving a hypoth
Jeff King writes:
> If you're really going to do a lot of interactive back-and-forth access
> of objects, though, I think you want to set up pipes to cat-file. It's a
> little tedious to allocate fifos, but something like:
With bash's coproc it's a bit less tedious:
> mkfifo in out
> (exec
Junio C Hamano wrote:
> Nice. Can we demonstrate and protect this fix with simple tests?
I just added the tests to t5570 since we don't use git://
much in the tests and I didn't want to introduce potential
port conflicts.
8<
Subject: [PATCH] pass transport verbos
On Thu, Jan 28, 2016 at 01:32:30PM -0800, Junio C Hamano wrote:
> Clemens Buchacher writes:
>
> > If we do this, then git diff should show the diff between
> > convert_to_worktree(index state) and the worktree state.
>
> And that unfortunately is a very good reason why this approach
> should not
Jeff King wrote:
> On Sat, Jan 30, 2016 at 02:21:26AM -0500, Jeff King wrote:
> > Even the commit porting rsync over to C from shell (cd547b4)
> > lists it as deprecated! So between the 10 years of informal
> > warnings, and the fact that it has been severely broken
> > since 2007, it's probably s
29 matches
Mail list logo
