It seems there were some changes at the keychain in macOS Sierra, after
upgrading git seems not to be able to find the client certificate required to
connect to our server.
fatal: unable to access 'https://xxx:8443/git/proj.git/': SSL: Can't find the
certificate "John Doe" and its private key i
> On 22 Sep 2016, at 18:56, Ramsay Jones wrote:
>
>
> Signed-off-by: Ramsay Jones
> ---
>
> Hi Lars,
>
> If you need to re-roll your 'ls/filter-process' branch, could you please
> squash this into the relevant commit c42a4cbc ("run-command: move check_pipe()
> from write_or_die to run_comman
The "highlight" binary can, in some cases, determine the language type
by the means of file contents, for example the shebang in the first line
for some scripting languages. Make use of this autodetection for files
which syntax is not known by gitweb. In that case, pass the blob
contents to "high
On Thu, Sep 22, 2016, at 03:50 PM, Jakub Narębski wrote:
> W dniu 22.09.2016 o 00:18, Ian Kelling napisał:
>
> > The highlight binary can detect language by shebang when we can't tell
> > the syntax type by the name of the file. In that case, pass the blob
> > to "highlight --force" and the resulti
Signed-off-by: Ian Kelling
---
gitweb/gitweb.perl | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 33d701d..6cb4280 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3913,7 +3913,7 @@ sub blob_contenttype {
# guess f
Stefan Beller wrote:
> On Thu, Sep 22, 2016 at 12:48 PM, Kevin Daudt wrote:
> > On Thu, Sep 22, 2016 at 07:33:11PM +, Anatoly Borodin wrote:
> >> Hi Stefan,
> >>
> >> this section was added to the manual in the commit
> >> cddb42d2c58a9de9b2b5ef68817778e7afaace3e by "Jonathan Nieder"
> >> 6
Anatoly Borodin wrote:
> PS There are also some pieces of "what should work" in these tests:
>
> t/t3409-rebase-preserve-merges.sh*
> t/t3410-rebase-preserve-dropped-merges.sh*
> t/t3411-rebase-preserve-around-merges.sh*
> t/t3414-rebase-preserve-onto.sh*
Thanks, this is interesting; I'm having
I use rev^..rev daily, and I'm surely not the only one. To save typing
(or copy-pasting, if the rev is long -- like a full SHA-1 or branch name)
we can make rev% a shorthand for that.
The existing syntax rev^! seems like it should do the same, but it
doesn't really do the right thing for merge com
Commit "init: do not set core.worktree more often than necessary" adds a
subtle dependency between set_git_dir_init() and init_db(). The former
_must_ be called before init_db() so that original_git_dir can be set
properly. If something else, like enter_repo() or setup_git_directory(),
is used inst
> OK, you said something about for_each_ref() in an earlier commit,
> but what you meant was this one, which takes each_tag_name_fn.
Oh yeah, sorry for the confusion.
>
> The function for_each_tag_name(), the type each_tag_name_fn, and the
> function of that type verify_tag(), are ALL file-scope
On Thu, Sep 22, 2016 at 02:16:21PM -0700, Junio C Hamano wrote:
> santi...@nyu.edu writes:
>
> > From: Santiago Torres
> >
> > Callers of verify-tag may want to cross-check the tagname from refs/tags
> > with the tagname from the tag object header upon GPG verification. This
> > is to avoid tag r
On Thu, Sep 22, 2016 at 01:58:06PM -0700, Junio C Hamano wrote:
> santi...@nyu.edu writes:
>
> > Calling functions for gpg_verify_tag() may desire to print relevant
> > information about the header for further verification. Add an optional
> > format argument to print any desired information after
Nguyễn Thái Ngọc Duy writes:
> I think a separate commit for this is better than combining back to
> 2/3 so we can explain the problem properly (without making 2/3 commit
> message even longer)
>
> Not sure if you want to s/contains/contain/ in 2/3 by yourself or I
> should resend the whole
li...@haller-berlin.de (Stefan Haller) writes:
> Thanks, this is interesting; I'm having trouble understanding the tests
> though. Some of them use rebase -p -i, but I don't understand why they
> use -i, or why that even works in a test (i.e. why it doesn't open an
> editor).
Upon starting up, te
Junio C Hamano wrote:
> li...@haller-berlin.de (Stefan Haller) writes:
>
> > Thanks, this is interesting; I'm having trouble understanding the tests
> > though. Some of them use rebase -p -i, but I don't understand why they
> > use -i, or why that even works in a test (i.e. why it doesn't open a
> Yeah, a positive "I support this" flag would at least let us correctly
> flag errors, which is the best we can do. That won't work for
> non-builtins, but perhaps it is good enough in practice.
>
> -Peff
So it sounds like we agree that this prefix option should be pushed to
the top level.
The q
On Fri, Sep 23, 2016 at 9:16 AM, Brandon Williams wrote:
>> Yeah, a positive "I support this" flag would at least let us correctly
>> flag errors, which is the best we can do. That won't work for
>> non-builtins, but perhaps it is good enough in practice.
>>
>> -Peff
>
>
> So it sounds like we agr
Vegard Nossum writes:
> I use rev^..rev daily, and I'm surely not the only one. To save typing
> (or copy-pasting, if the rev is long -- like a full SHA-1 or branch name)
> we can make rev% a shorthand for that.
No, we cannot.
'%' is not reserved as a special character that is forbidden in
refe
Lars Schneider writes:
>> If you need to re-roll your 'ls/filter-process' branch, could you please
>> squash this into the relevant commit c42a4cbc ("run-command: move
>> check_pipe()
>> from write_or_die to run_command", 20-09-2016).
>>
>> [Note that commit 9658846c ("write_or_die: handle EPIP
The MAX_IN_VAIN mechanism was introduced in commit f061e5f ("fetch-pack:
give up after getting too many "ack continue"", 2006-05-24) to stop ref
negotiation if a number of consecutive "have"s have been sent with no
corresponding new acks. This is to stop the client from digging too deep
in an irrel
Brandon Williams writes:
> - /* Find common prefix for all pathspec's */
> - max_prefix = common_prefix(&pathspec);
> + /*
> + * Find common prefix for all pathspec's
> + * This is used as a performance optimization which unfortunately cannot
> + * be done when recursin
> On 23 Sep 2016, at 19:13, Junio C Hamano wrote:
>
> Lars Schneider writes:
>
>>> If you need to re-roll your 'ls/filter-process' branch, could you please
>>> squash this into the relevant commit c42a4cbc ("run-command: move
>>> check_pipe()
>>> from write_or_die to run_command", 20-09-2016)
Brandon Williams writes:
> static void show_ce_entry(const char *tag, const struct cache_entry *ce)
> {
> + struct strbuf name = STRBUF_INIT;
> int len = max_prefix_len;
> + if (submodule_prefix)
> + strbuf_addstr(&name, submodule_prefix);
> + strbuf_addstr(&name,
Am 23.09.2016 um 17:50 schrieb Stefan Haller:
And I don't see any tests that do rebase -p -i and actually do something
interesting with the -i part. So my original question still remains. :-)
-i -p came first. -p without -i was bolted on later.
-- Hannes
Lars Schneider writes:
>> I do not offhand know if the topic is otherwise ready as-is, or
>> needs further work. When you need to reroll, you'd also need to
>> fetch from the result of the above from me first and then start your
>> work from it, though, if we go that route.
>
> Sounds good to me
Jonathan Tan writes:
> I tried looking at creating a helper function to reduce both the size
> and the nesting level of the loop, but it seems to me that a helper
> function can't be extracted so easily because the logic is quite
> intertwined with the rest of the function. For example, the "if
>
W dniu 23.09.2016 o 11:08, Ian Kelling napisał:
>
> Subject: [PATCH v3 1/2] gitweb: remove unused function parameter
I think it would be better to be more descriptive, and say:
Subject: [PATCH v3 1/2] gitweb: remove unused parameter from
guess_file_syntax()
But that might be too long...
>
>
Jakub Narębski writes:
> I think it would be better to be more descriptive, and say:
>
> Subject: [PATCH v3 1/2] gitweb: remove unused parameter from
> guess_file_syntax()
> Acked-by: Jakub Narębski
Thanks.
On Fri, Sep 23, 2016 at 12:20 PM, Junio C Hamano wrote:
> There is an interesting observation around this code. Note that it
> is just something to keep in mind, even though I think we are in no
> position to solve this within the scope of this series, or in fact I
> am not sure if there is anyth
Hi,
On Wed, 21 Sep 2016, Junio C Hamano wrote:
> * rt/rebase-i-broken-insn-advise (2016-09-07) 1 commit
> - rebase -i: improve advice on bad instruction lines
>
> When "git rebase -i" is given a broken instruction, it told the
> user to fix it with "--edit-todo", but didn't say what the step
Hi,
On Thu, 22 Sep 2016, Stefan Beller wrote:
> On Thu, Sep 22, 2016 at 2:01 PM, Anatoly Borodin
> wrote:
> > Hi Stefan,
> >
> > I've also done some archaeology and found that the original version of
> > the merge preserving code was written by Johannes Schindelin
> > , see e.g.
>
> I think it
Hi Stefan,
On Fri, 23 Sep 2016, Stefan Haller wrote:
> Stefan Beller wrote:
>
> > On Thu, Sep 22, 2016 at 12:48 PM, Kevin Daudt wrote:
> > > On Thu, Sep 22, 2016 at 07:33:11PM +, Anatoly Borodin wrote:
> > >> Hi Stefan,
> > >>
> > >> this section was added to the manual in the commit
> > >
W dniu 23.09.2016 o 11:08, Ian Kelling napisał:
> The "highlight" binary can, in some cases, determine the language type
> by the means of file contents, for example the shebang in the first line
> for some scripting languages. Make use of this autodetection for files
> which syntax is not known
On Fri, Sep 23, 2016 at 2:13 PM, Johannes Schindelin
wrote:
> Hi Stefan,
>
> On Fri, 23 Sep 2016, Stefan Haller wrote:
>
>> Stefan Beller wrote:
>>
>> > On Thu, Sep 22, 2016 at 12:48 PM, Kevin Daudt wrote:
>> > > On Thu, Sep 22, 2016 at 07:33:11PM +, Anatoly Borodin wrote:
>> > >> Hi Stefan,
W dniu 22.09.2016 o 20:26, Junio C Hamano napisał:
> Kevin Daudt writes:
>
>> Often people advise tricks like `git update-index --assume-unchanges
>> `, but this does not work as expected. It's merely a promise to
>> git that this file does not change (and hence, git will not check if
>> this fil
Nguyễn Thái Ngọc Duy writes:
> I think a separate commit for this is better than combining back to
> 2/3 so we can explain the problem properly (without making 2/3 commit
> message even longer)
>
> Not sure if you want to s/contains/contain/ in 2/3 by yourself or I
> should resend the whole
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.
A bunch of topics have graduated t
On Wed, Sep 21, 2016 at 11:20 PM, Jeff King wrote:
>> +/**
>> + * Recursively call ls-files on a submodule
>> + */
>> +static void show_gitlink(const struct cache_entry *ce)
>> +{
>> + struct child_process cp = CHILD_PROCESS_INIT;
>> + int status;
>> +
>> + argv_array_push(&cp.args, "l
After looking at the feedback I rerolled a few things, in particular the
--submodule_prefix option that existed to give a submodule context about where
it had been invoked from. People didn't seem to like the idea of exposing this
to the users (yet anyways) so I removed it as an option and instead
Allow ls-files to recognize submodules in order to retrieve a list of
files from a repository's submodules. This is done by forking off a
process to recursively call ls-files on all submodules. Use environment
variable `GIT_INTERNAL_SUBMODULE_PREFIX` to pass a path to the submodule
which it can us
Pathspecs can be a bit tricky when trying to apply them to submodules.
The main challenge is that the pathspecs will be with respect to the
superproject and not with respect to paths in the submodule. The
approach this patch takes is to pass in the identical pathspec from the
superproject to the s
Add a submodule-prefix enviorment variable
'GIT_INTERNAL_SUBMODULE_PREFIX' which can be used by commands which have
--recurse-submodule options.
Signed-off-by: Brandon Williams
---
cache.h | 1 +
environment.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/cache.h b/cache.h
index 35
On 23/09/16 20:26, Junio C Hamano wrote:
> Lars Schneider writes:
>
>>> I do not offhand know if the topic is otherwise ready as-is, or
>>> needs further work. When you need to reroll, you'd also need to
>>> fetch from the result of the above from me first and then start your
>>> work from it,
43 matches
Mail list logo