Denton Liu writes:
> There has been a push to remove extern from function declarations.
> Finish the job by removing all instances of "extern" for function
> declarations in headers using sed.
>
> This was done by running the following on my system with sed 4.2.2:
>
> $ git ls-files \*.{c,h}
Jeff King writes:
> I.e., I think the conversation ought to be more like:
>
> Server: I support packfile-uris X, Y, Z.
>
> Client: Great. I'll use URIs X and Z.
>
> Server: OK, here's your pack, minus any objects I know are in X and Z.
> I'll send you the objects from Y as normal.
"brian m. carlson" writes:
> On Wed, Apr 24, 2019 at 11:09:10AM +0900, Junio C Hamano wrote:
>> "brian m. carlson" writes:
>>
>> > To preserve backwards compatibility, we don't run the hooks in the ".d"
>> > directory if the single file is a valid hook (i.e. it exists and is
>> > executable). T
Hi,
brian m. carlson wrote:
> I've talked with some people about this approach, and they've indicated
> they would prefer a configuration-based approach.
I would, too, mostly because that reduces the problem of securing
hooks to securing configuration. See
https://public-inbox.org/git/201710022
"brian m. carlson" writes:
> diff --git a/builtin/commit.c b/builtin/commit.c
> index f17537474a..e7cf6b16ba 100644
> --- a/builtin/commit.c
> +++ b/builtin/commit.c
> @@ -666,6 +666,7 @@ static int prepare_to_commit(const char *index_file,
> const char *prefix,
> struct strbuf sb = STRBUF
On Wed, Apr 24, 2019 at 11:09:10AM +0900, Junio C Hamano wrote:
> "brian m. carlson" writes:
>
> > To preserve backwards compatibility, we don't run the hooks in the ".d"
> > directory if the single file is a valid hook (i.e. it exists and is
> > executable). This is because some people already h
"brian m. carlson" writes:
> To preserve backwards compatibility, we don't run the hooks in the ".d"
> directory if the single file is a valid hook (i.e. it exists and is
> executable). This is because some people already have multiple hook
> scripts configured, and if we ran them both, we'd run
Hi,
Jeff King wrote:
> The description for the "-t" option contains a sub-list of all of the
> possible file status outputs. But because of the newline separating that
> list from the description paragraph, asciidoc treats the sub-list
> entries as a continuation of the overall options list, rathe
Elijah Newren writes:
> ..., and passing a config-related callback function to
> parse_options seems a little weird to me.
A little? That's a moderate understatement.
If parse_options API were the ONLY thing that gets affected by
precompose_unicode, having an "if the config has not been read y
Hello! The Git Test Coverage Report returns. You can view it online [1] with
links to the associated commits on GitHub, or the text report [2] also copied
below.
Thanks,
-Stolee
[1] https://derrickstolee.github.io/git-test-coverage/reports/2019-04-23.htm
[2] https://derrickstolee.github.io/git-te
Jeff King writes:
> Commit 05eb1c37ed (perf/aggregate: implement codespeed JSON output,
> 2018-01-05) added a dependency on the perl JSON module to show output
> from aggregate.perl, but we only need it when the user asks for
> --codespeed output. While the module is pretty common, it's not part
On Wed, Apr 24, 2019 at 09:55:04AM +0900, Junio C Hamano wrote:
> "brian m. carlson" writes:
>
> > What POSIX says on this is the following:
> >
> > If any access permissions are checked, each shall be checked
> > individually, as described in XBD File Access Permissions, except that
> > wh
Duy Nguyen writes:
> On Mon, Apr 22, 2019 at 1:14 PM Denton Liu wrote:
>>
>> In revisions.txt, the '^' form is mentioned but the '~' form
>> is missing. Although both forms are essentially equivalent (they each
>> get the first parent of the specified revision), we should mention the
>> latter f
SZEDER Gábor writes:
> I remember being rather puzzled by 'git ls-files' listing the same
> file more than once depending on its --options when I was working on
> the git-aware path completion parts of our completion script.
Yup, I recall a thread we recently had where we wondered why we see
two
Oftentimes, people want to use multiple of the same kind of hook. This
may be because software or a project they use requires a given hook, but
they would also like to have a custom hook, or because they're using
multiple pieces of software that both require involvement with the same
hook.
This se
Add support for multiple hooks for the pre-receive, post-receive,
update, post-update, and push-to-checkout hooks. Add tests for these
hooks using the multiple hook test framework.
Because the invocations of test_multiple_hooks contain multiple test
assertions, they (and the cd commands that surro
"brian m. carlson" writes:
> What POSIX says on this is the following:
>
> If any access permissions are checked, each shall be checked
> individually, as described in XBD File Access Permissions, except that
> where that description refers to execute permission for a process with
> appro
Add support for multiple post-rewrite hooks, both for "git commit
--amend" and "git rebase".
Additionally add support for multiple prepare-commit-msg hooks.
Signed-off-by: brian m. carlson
---
builtin/am.c | 28 ++---
sequencer.c| 96 +++
Add support for multiple pre-push hooks.
Remove find_hook since there are no longer any callers of it.
Signed-off-by: brian m. carlson
---
run-command.c| 12 -
run-command.h| 6 ---
t/t5571-pre-push-hook.sh | 19
transport.c | 98 ++
Add support for multiple post-checkout hooks. We test only one possible
path in the multiple hook case because the same code path is used for
all checkouts and we know the hooks work from earlier assertions.
Signed-off-by: brian m. carlson
---
builtin/worktree.c| 40 +
A variety of types of software take advantage of Git's hooks. However,
if a user would like to integrate multiple pieces of software which use
a particular hook, they currently must manage those hooks themselves,
which can be burdensome. Sometimes various pieces of software try to
overwrite each ot
"CHIGOT, CLEMENT" writes:
> From: Junio C Hamano on behalf of Junio C Hamano
>
>> > On some OSes like AIX, access with X_OK is always true if launched under
>> > root.
>>
>> That may be the case, but you'd need to describe why it is a problem
>> here, before talking about the need for a "work
On Tue, Apr 23, 2019 at 11:31:02AM +, CHIGOT, CLEMENT wrote:
> From: Junio C Hamano on behalf of Junio C Hamano
>
> This patch is needed in order to have hooks working on AIX. When run as root,
> access on hooks will return true even if a hook can't be executed. Therefore,
> as far as I know
There has been a push to remove extern from function declarations.
Finish the job by removing all instances of "extern" for function
declarations in headers using sed.
This was done by running the following on my system with sed 4.2.2:
$ git ls-files \*.{c,h} | \
grep -v ^compat/ | \
In previous patches, extern was mechanically removed from function
declarations without care to formatting, causing parameter lists to be
misaligned. Manually format changed sections such that the parameter
lists should be realigned.
Viewing this patch with 'git diff -w' should produce no output.
Since function declarations already implicitly imply extern, create a
Coccinelle rule which removes the redundant extern.
Signed-off-by: Denton Liu
---
contrib/coccinelle/noextern.cocci | 6 ++
1 file changed, 6 insertions(+)
create mode 100644 contrib/coccinelle/noextern.cocci
diff --git
Thanks for the review, Peff.
I've excluded all the files under compat/ from being changed as it's
easier this way. After this patchset is merged, I'll probably get around
to removing the externs from compat/ files later (the ones that aren't
copied from some external source) but for now, this patc
Hi Junio,
On Sun, Apr 21, 2019 at 01:11:18AM -0700, Denton Liu wrote:
> Signed-off-by: Denton Liu
> ---
> t/t3431-rebase-fork-point.sh | 53
> 1 file changed, 53 insertions(+)
> create mode 100755 t/t3431-rebase-fork-point.sh
>
> diff --git a/t/t3431-rebase
Ævar Arnfjörð Bjarmason wrote:
> On Wed, Apr 24 2019, Jonathan Nieder wrote:
>> Do you mean this for when a pack is self-contained and contains all
>> objects reachable from those "tip" commits?
>>
>> What would you do when a pack is not self-contained in that way?
>
> Indeed, it had been a while
Ævar Arnfjörð Bjarmason wrote:
> On Wed, Apr 24 2019, Jonathan Nieder wrote:
>> Jeff King wrote:
>>> On Fri, Mar 08, 2019 at 01:55:17PM -0800, Jonathan Tan wrote:
+If the 'packfile-uris' feature is advertised, the following argument
+can be included in the client's request as well as the
On Wed, Apr 24 2019, Jonathan Nieder wrote:
> Hi,
>
> Ævar Arnfjörð Bjarmason wrote:
>
>> This is really orthagonal to this series, but wouldn't a better
>> resumption strategy here be to walk the pack we just downloaded, run the
>> equivalent of 'commit-graph write' on it to figure out likely "
Hi everyone!
A draft of a new Git Rev News edition is available here:
https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-50.md
Everyone is welcome to contribute in any section either by editing the
above page on GitHub and sending a pull request, or by commenting on
this
On Wed, Apr 24 2019, Jonathan Nieder wrote:
> Hi,
>
> Jeff King wrote:
>> On Fri, Mar 08, 2019 at 01:55:17PM -0800, Jonathan Tan wrote:
>
>>> +If the 'packfile-uris' feature is advertised, the following argument
>>> +can be included in the client's request as well as the potential
>>> +addition
Hi,
Ævar Arnfjörð Bjarmason wrote:
> This is really orthagonal to this series, but wouldn't a better
> resumption strategy here be to walk the pack we just downloaded, run the
> equivalent of 'commit-graph write' on it to figure out likely "tip"
> commits, and use those in "have" lines to negotia
On Tue, Apr 23 2019, Jonathan Tan wrote:
>> The problem I see is that the client doesn't get to vet the list of
>> URIs; it only gets to specify a protocol match. But there are many other
>> reasons it might want to reject a URI: we don't like the protocol, the
>> domain name is on a blacklist (
Hi,
Jeff King wrote:
> On Fri, Mar 08, 2019 at 01:55:17PM -0800, Jonathan Tan wrote:
>> +If the 'packfile-uris' feature is advertised, the following argument
>> +can be included in the client's request as well as the potential
>> +addition of the 'packfile-uris' section in the server's response a
Hi Michael -
I cobbled something together that passes my old git tests and all but
one of your tests, though an assertion fails when I use it for real.
See below.
On 4/22/19 6:26 PM, mich...@platin.gs wrote:
[snip]
+static int *get_similarity(int *similarities, int max_search_distance_a,
+
> The problem I see is that the client doesn't get to vet the list of
> URIs; it only gets to specify a protocol match. But there are many other
> reasons it might want to reject a URI: we don't like the protocol, the
> domain name is on a blacklist (or not on a whitelist), the domain name
> can't
On Mon, Apr 22, 2019 at 10:49:27AM -0400, Jeff King wrote:
> On Sun, Apr 21, 2019 at 10:19:04PM +0900, Junio C Hamano wrote:
>
> >I am not fan of adding the "| sort -u" of the whole thing,
> >because there is no need to dedup the output of the $(FIND) side
> >of the alternative, but "(
Hi Michael -
FYI, here are a few style nits that I changed in my version, based on a
quick scan. Not sure if these are all Git's style, but I think it's
mostly linux-kernel style.
I mention this mostly for future reference - specifically if we keep
separate versions of this code. Hopefully
Hello,
Could you check this github issue:
https://github.com/libssh2/libssh2/issues/360
There are two strange commits from 'fullermd':
https://github.com/libssh2/libssh2/commits?author=fullermd
Both pretend to change a typo - but they inject a huge amount of code.
Best wishes
Eva
On Tuesday, April 23, 2019 5:08:40 PM MDT Duy Nguyen wrote:
> On Tue, Apr 23, 2019 at 11:45 AM Jeff King wrote:
> > On Mon, Apr 22, 2019 at 09:55:38PM -0400, Jeff King wrote:
> > > Here are my p5302 numbers on linux.git, by the way.
> > >
> > > Test jk/
This tutorial covers how to add a new command to Git and, in the
process, everything from cloning git/git to getting reviewed on the
mailing list. It's meant for new contributors to go through
interactively, learning the techniques generally used by the git/git
development community.
Signed-off-by
> On Fri, Mar 08, 2019 at 01:55:12PM -0800, Jonathan Tan wrote:
>
> > Here's my current progress - the only thing that is lacking is more
> > tests, maybe, so I think it's ready for review.
>
> A bit belated, but here are some overall thoughts. A lot of my thinking
> comes from comparing this to
On Tue, Apr 23, 2019 at 11:29 AM Torsten Bögershausen wrote:
>
> On Tue, Apr 23, 2019 at 10:30:56AM -0700, Elijah Newren wrote:
> > On Mac's HFS ("Hilarious FileSystem"? "Halfwitted FileSystem"?) --
>
> How about "Hierarchical File System" ?
Sorry, I should have removed my draft commentary befor
On Tue, Apr 23, 2019 at 10:30:56AM -0700, Elijah Newren wrote:
> On Mac's HFS ("Hilarious FileSystem"? "Halfwitted FileSystem"?) --
How about "Hierarchical File System" ?
> where git sets core.precomposeUnicode to true automatically by git
> init/clone -- when a user creates a simple unicode ref
Hi Michael -
On 4/22/19 6:26 PM, mich...@platin.gs wrote:
+ int *matching_lines = fuzzy_find_matching_lines(parent->file.ptr,
+ target->file.ptr,
+ parent->line_starts,
+
On Mac's HFS ("Hilarious FileSystem"? "Halfwitted FileSystem"?) --
where git sets core.precomposeUnicode to true automatically by git
init/clone -- when a user creates a simple unicode refname (in NFC
format) such as españa:
$ git branch españa
different commands would display the branch name
On Thu, Apr 11, 2019 at 6:09 PM Thomas Gummerer wrote:
>
> On 04/10, Matheus Tavares Bernardino wrote:
> > > > diff --git a/dir-iterator.h b/dir-iterator.h
> > > > index 970793d07a..93646c3bea 100644
> > > > --- a/dir-iterator.h
> > > > +++ b/dir-iterator.h
> > > > @@ -19,7 +19,7 @@
> > > > * A
Hi Everyone,
When working on Windows I often use the Terminal provided by Git to
SSH into other machines. I've noticed select/copy/paste does not work
as expected when there is a lot of scrollback. It works, but it takes
minutes to select the text and copy from the terminal.
For example, clear th
Hi Philip
Thanks for answering.
I will try to post an issue.
The 408 line is simply this:
cat
(btw cat command alone seems to work in my pc)
the 636 is more complex:
parents=$(git rev-parse "$rev^@")
it is inside the process_split_commit () function
On 4/22/19 6:26 PM, mich...@platin.gs wrote:
From: Michael Platings
Hi Barret,
This patch is on top of your patch v6 4/6.
Thanks, I'll take a look. I was working on taking your old version and
integrating it with my v6 6/6. That way it gets the
origin-fingerprint-filling code and can be
On 4/22/19 1:47 PM, Ævar Arnfjörð Bjarmason wrote:
>
> On Mon, Apr 22 2019, Andrew Janke wrote:
>
>> On 4/21/19 8:35 PM, Duy Nguyen wrote:
>>> On Sun, Apr 21, 2019 at 6:40 PM Andrew Janke wrote:
Hi, Git folks,
This is a follow-up to https://marc.info/?l=git&m=1547579384297
From: Junio C Hamano on behalf of Junio C Hamano
> > On some OSes like AIX, access with X_OK is always true if launched under
> > root.
>
> That may be the case, but you'd need to describe why it is a problem
> here, before talking about the need for a "work around".
>
> For example, if a dire
"CHIGOT, CLEMENT" writes:
> On some OSes like AIX, access with X_OK is always true if launched under
> root.
That may be the case, but you'd need to describe why it is a problem
here, before talking about the need for a "work around".
For example, if a directory on $PATH has a file called git-f
On Tue, Apr 23, 2019 at 3:41 PM CHIGOT, CLEMENT wrote:
>
> On some OSes like AIX, access with X_OK is always true if launched under
> root.
> Add NEED_ACCESS_ROOT_HANDLER in order to use an access helper function.
> It checks with stat if any executable flags is set when the current user
> is root
On Tue, Apr 23, 2019 at 11:45 AM Jeff King wrote:
>
> On Mon, Apr 22, 2019 at 09:55:38PM -0400, Jeff King wrote:
>
> > Here are my p5302 numbers on linux.git, by the way.
> >
> > Test jk/p5302-repeat-fix
> >
When typing "git status", there is an empty line between
the "Changes not staged for commit:" block and the list
of changed files. However, when typing "git commit" with
no files added, there are no empty lines between them.
This patch adds empty lines in the above case and some
similar cases.
Si
In 063f2bdbf7 (mergetool: accept -g/--[no-]gui as arguments,
2018-10-24), mergetool was taught the --gui option but no tests were
added to ensure that it was working properly. Add a test to ensure that
it works.
Signed-off-by: Denton Liu
---
t/t7610-mergetool.sh | 22 ++
1 fi
Thanks for the review, Eric.
Hopefully, these changes have addressed the concerns that you've raised.
---
Changes since v1:
* Introduce get_merge_tool_guessed function instead of changing
get_merge_tool
* Remove unnecessary if-tower in mutual exclusivity logic
Denton Liu (5):
t7610: add me
In git-mergetool, the logic for getting which merge tool to use is
duplicated in git-mergetool--lib, except for the fact that it needs to
know whether the tool was guessed or not.
Write `get_merge_tool_guessed` to return whether or not the tool was
guessed in addition to the actual tool and make g
In git-difftool, if the tool is called with --gui but `diff.guitool` is
not set, it falls back to `diff.tool`. Make git-mergetool also fallback
from `merge.guitool` to `merge.tool` if the former is undefined.
If git-difftool were to use `get_configured_mergetool`, it would also
get the fallback be
In git-difftool.txt, it says
'git difftool' falls back to 'git mergetool' config variables when the
difftool equivalents have not been defined.
However, when `diff.guitool` is missing, it doesn't fallback to
anything. Make git-difftool fallback to `merge.guitool` when `diff.guitoo
In git-difftool, these options specify which tool to ultimately run. As
a result, they are logically conflicting. Explicitly disallow these
options from being used together.
Signed-off-by: Denton Liu
---
builtin/difftool.c | 3 +++
t/t7800-difftool.sh | 8
2 files changed, 11 insertion
On some OSes like AIX, access with X_OK is always true if launched under
root.
Add NEED_ACCESS_ROOT_HANDLER in order to use an access helper function.
It checks with stat if any executable flags is set when the current user
is root.
Signed-off-by: Clément Chigot
---
Makefile | 8 ++
On Mon, Apr 22 2019, Jeff King wrote:
> On Mon, Apr 22, 2019 at 08:01:15PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> > Your patch is optionally removing the "woah, we got an object with a
>> > duplicate sha1, let's check that the bytes are the same in both copies"
>> > check. But Martin's probl
66 matches
Mail list logo
