Re: [PATCH] run-command: async_exit no longer needs to be public

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

[PATCH 1/3 v3] submodules: make submodule-prefix option an envvar

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

[PATCH 2/3 v3] ls-files: optionally recurse into submodules

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

[PATCH 3/3 v3] ls-files: add pathspec matching for submodules

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

[PATCH 0/3] recursive support for ls-files

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

Re: [PATCH 1/2] ls-files: optionally recurse into submodules

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; >> + >> +

What's cooking in git.git (Sep 2016, #07; Fri, 23)

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

Re: [PATCH v2 4/3] init: combine set_git_dir_init() and init_db() into one

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 >

Re: .gitignore does not ignore Makefile

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

Re: Limitiations of git rebase --preserve-merges --interactive

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,

Re: [PATCH v3 2/2] gitweb: use highlight's shebang detection

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

Re: Limitiations of git rebase --preserve-merges --interactive

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

Re: Limitiations of git rebase --preserve-merges --interactive

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 > >

Re: What's cooking in git.git (Sep 2016, #06; Wed, 21)

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

Re: [PATCH 2/2 v2] ls-files: add pathspec matching for submodules

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

Re: [PATCH v3 1/2] gitweb: remove unused function parameter

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.

Re: [PATCH v3 1/2] gitweb: remove unused function parameter

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... > >

Re: [PATCH v2] fetch-pack: do not reset in_vain on non-novel acks

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

Re: [PATCH] run-command: async_exit no longer needs to be public

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

Re: Limitiations of git rebase --preserve-merges --interactive

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

Re: [PATCH 2/2 v2] ls-files: add pathspec matching for submodules

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(, submodule_prefix); > +

Re: [PATCH] run-command: async_exit no longer needs to be public

> 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() >>>

Re: [PATCH 2/2 v2] ls-files: add pathspec matching for submodules

Brandon Williams writes: > - /* Find common prefix for all pathspec's */ > - max_prefix = common_prefix(); > + /* > + * Find common prefix for all pathspec's > + * This is used as a performance optimization which unfortunately cannot > + * be done

[PATCH v2] fetch-pack: do not reset in_vain on non-novel acks

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

Re: [PATCH] run-command: async_exit no longer needs to be public

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

Re: [RFC PATCH] revision: new rev%n shorthand for rev^n..rev

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

Re: [PATCH 1/2] ls-files: adding support for submodules

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

Re: [PATCH 1/2] ls-files: adding support for submodules

> 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

Re: Limitiations of git rebase --preserve-merges --interactive

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,

Re: [PATCH v2 4/3] init: combine set_git_dir_init() and init_db() into one

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 >

Re: [PATCH 4/6] tag: add format specifier to gpg_verify_tag

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

Re: [PATCH 5/6] builtin/verify-tag: Add --format to verify-tag

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 >

Re: [PATCH 6/6] builtin/tag: add --format argument for tag -v

> 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

[PATCH v2 4/3] init: combine set_git_dir_init() and init_db() into one

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

[RFC PATCH] revision: new rev%n shorthand for rev^n..rev

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

Re: Limitiations of git rebase --preserve-merges --interactive

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,

Re: Limitiations of git rebase --preserve-merges --interactive

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 > >>

Re: [PATCH v2] gitweb: use highlight's shebang detection

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

[PATCH v3 2/2] gitweb: use highlight's shebang detection

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

[PATCH v3 1/2] gitweb: remove unused function parameter

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

Re: [PATCH] run-command: async_exit no longer needs to be public

> 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

Keychain access does not work under macOS Sierra

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

Re: [PATCH 1/2] ls-files: adding support for submodules

On Thu, Sep 22, 2016 at 10:47:17PM -0700, Stefan Beller wrote: > On Thu, Sep 22, 2016 at 8:41 PM, Jeff King wrote: > > >> * As Stefan alluded to (much) earlier, it might be a better idea > >>to have these 'prefix' as the global option to "git" potty, not > >>to each