On Fri, Oct 26, 2018 at 11:48:38AM +0900, Junio C Hamano wrote:
> tbo...@web.de writes:
>
> > From: Torsten Bögershausen
>
> > Subject: Re: [PATCH v1 2/2] curl_off_t xcurl_off_t is not portable
>
> That title is misleading; it sounded as if the are these two
> typedefs and they do not work
On Fri, Oct 26 2018, Jeff King wrote:
> On Sat, Oct 20, 2018 at 02:58:53PM -0400, Jeff King wrote:
>
>> On Sat, Oct 20, 2018 at 01:14:28PM +0200, Ævar Arnfjörð Bjarmason wrote:
>>
>> > > I'd guess this sort of thing is pretty rare. But I wonder if we're
>> > > crossing the line of trying to
One other option is to just use a pattern that matches everything, i.e:
echo '*' > .gitignore
And take advantage that ignore rules do not apply to tracked files.
So instead of using an explicit .gitonly, you add files using:
git add -f
All files should be ignored except the ones that
On 10/23/2018 4:28 PM, Jeff King wrote:
On Thu, Oct 18, 2018 at 08:05:22PM +0200, Nguyễn Thái Ngọc Duy wrote:
On Thu, Oct 18, 2018 at 7:09 PM Jeff King wrote:
In this particular case though I think we should be able to avoid so
much #if if we make a wrapper for pthread api that would
On Fri, Oct 26, 2018 at 02:39:26PM +0200, Ævar Arnfjörð Bjarmason wrote:
> On Fri, Oct 26 2018, Jeff King wrote:
> > On Thu, Oct 25, 2018 at 10:38:46AM -0400, Jason Cooper wrote:
> >> On 10/25/18 1:37 AM, Junio C Hamano wrote:
> >> > "lhf...@163.com" writes:
> >> >> I have a good idea, add a file
On Thu, Oct 11 2018, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> On Wed, Oct 10 2018, Jeff King wrote:
>>
>>> This is much better, and I love the customized behavior based on the
>>> object type.
>>>
>>> I wonder if we could reword the first paragraph to be a little less
>>>
Phillip Wood writes:
>> I spotted a weird corner case buglet, but it seems that this one is
>> ready for 'next' even without fixing that "give it three times and
>> we will happily continue" thing.
>
> Well spotted on the corner case. If you're happy to hold off on moving
> it to next I can send
Hi Junio,
On Fri, 26 Oct 2018, Junio C Hamano wrote:
> * js/mingw-http-ssl (2018-10-26) 3 commits
> (merged to 'next' on 2018-10-26 at 318e82e101)
> + http: when using Secure Channel, ignore sslCAInfo by default
> + http: add support for disabling SSL revocation checks in cURL
> + http: add
Johannes Schindelin writes:
> Hi Junio,
>
> On Fri, 26 Oct 2018, Junio C Hamano wrote:
>
>> * js/mingw-http-ssl (2018-10-26) 3 commits
>> (merged to 'next' on 2018-10-26 at 318e82e101)
>> + http: when using Secure Channel, ignore sslCAInfo by default
>> + http: add support for disabling SSL
On Fri, Oct 26, 2018 at 01:34:53PM +, Jason Cooper wrote:
> On Fri, Oct 26, 2018 at 02:39:26PM +0200, Ævar Arnfjörð Bjarmason wrote:
...
> > I thought this was a bug:
> >
> > (
> > rm -rf /tmp/git &&
> > git init /tmp/git &&
> > cd /tmp/git
On Fri, Oct 26, 2018 at 01:31:51PM +0200, Mischa POSLAWSKY wrote:
> Jeff King wrote 2018-10-26 5:36 (-0400):
> > I think what Junio meant is to ignore everything by default, like:
> >
> > echo '*' >.gitignore
> >
> > and then selectively use negative patterns (and being in .gitignore,
> >
Thanks.
I think this one is identical to what has already been queued and
nerged to 'next'.
k
> Reviewed-by: Jonathan Tan
Probably better not to include such lines, especially since the review
by me is not yet complete.
Having said that, patches 1-5 look good to me. Patches 1-3 are identical
to the previous version, which I have already reviewed. In patch 4,
Stefan made the code change
Derrick Stolee writes:
> On 10/22/2018 9:37 AM, Jakub Narebski wrote:
>> "Derrick Stolee via GitGitGadget" writes:
[...]
>> Sidenote: the new algorithm looks a bit like Unix pipeline, where each
>> step of pipeline does not output much more than next step needs /
>> requests.
>
> That's
Jeff King wrote 2018-10-26 5:36 (-0400):
> I think what Junio meant is to ignore everything by default, like:
>
> echo '*' >.gitignore
>
> and then selectively use negative patterns (and being in .gitignore,
> that makes them positive "yes, include this") to add things back:
>
> echo 'foo'
On Fri, Oct 26 2018, Jeff King wrote:
> On Thu, Oct 25, 2018 at 10:38:46AM -0400, Jason Cooper wrote:
>
>> On 10/25/18 1:37 AM, Junio C Hamano wrote:
>> > "lhf...@163.com" writes:
>> >
>> >> I have a good idea, add a file to git that is the opposite of
>> >> .gitignore...,
>> > Do negative
>
> * sb/strbuf-h-update (2018-09-29) 1 commit
> (merged to 'next' on 2018-10-26 at e4ad935cb0)
> + strbuf.h: format according to coding guidelines
>
> Code clean-up to serve as a BCP example.
>
> Will merge to 'master'.
> Further clean-up patches may need to follow soon before this
>
Bonjour
Vous aviez besoin de prêts d'argent entre particuliers pour faire face
aux difficultés financières pour enfin sortir de l'impasse que
provoquent les banques, par le rejet de vos dossiers de demande de
crédits ?
Je suis un citoyen français à la retraite en mesure de vous faire
un prêt de
On Thu, Oct 25, 2018 at 6:59 PM Junio C Hamano wrote:
>
> Stefan Beller writes:
>
> >> In this series I am addressing the comments by Stefan Beller about the
> >> tests in patch 9.
> >>
> >> If the new tests look OK, I'd say we try moving the series to "next" and
> >> see what happens?
> >
> >
On Thu, Oct 25 2018, Jeff King wrote:
> On Thu, Oct 25, 2018 at 02:24:41AM +0100, Ramsay Jones wrote:
>
>> >> Yeah, my thinko. The latter would be closer to what this patch
>> >> wants to have, but obviously the former would be more flexible and
>> >> useful in wider context. Both have the
> diff --git a/builtin/grep.c b/builtin/grep.c
> index 7da8fef31a..ba7634258a 100644
> --- a/builtin/grep.c
> +++ b/builtin/grep.c
> @@ -418,7 +418,10 @@ static int grep_submodule(struct grep_opt *opt, struct
> repository *superproject,
> const struct object_id *oid,
>
> We used to recurse into submodules, even if they were broken having
> only an objects directory. The child process executed in the submodule
> would fail though if the submodule was broken.
>
> This patch tightens the check upfront, such that we do not need
> to spawn a child process to find
Mark up the error(...) messages in remote.c for translation. The likes
of "unable to push to unqualified destination" are relatively big
parts of the UI, i.e. error messages shown when "git push" fails.
I don't think any of these are plumbing, an the entire test suite
passes when running the
Add DWYM support for pushing a ref in refs/remotes/* when the
ref is unqualified, e.g.:
git push origin refs/remotes/origin/master:upstream-master
Before this we wouldn't know what do do with
refs/remotes/origin/master, now we'll look it up and discover that
it's a commit (or tag) and add a
Add an advice to the recently improved error message added in
f8aae12034 ("push: allow unqualified dest refspecs to DWIM",
2008-04-23).
Now with advice.pushUnqualifiedRefName=true (on by default) we show a
hint about how to proceed:
$ ./git-push avar v2.19.0^{commit}:newbranch -n
error:
Improve the error message added in f8aae12034 ("push: allow
unqualified dest refspecs to DWIM", 2008-04-23), which before this
change looks like this:
$ git push avar v2.19.0^{commit}:newbranch -n
error: unable to push to unqualified destination: newbranch
The destination refspec
Add a test asserting that "git push origin :" where is
a branch, tag, tree or blob in refs/remotes/* doesn't DWYM when
is unqualified. This has never worked, but there's been no test for
this behavior.
See f88395ac23 ("Renaming push.", 2005-08-03), bb9fca80ce ("git-push:
Update description of
A follow-up change will extend this error message with the advice
facility. Doing so would make the indentation too deeply nested for
comfort. So let's split this into a helper function.
There's no changes to the wording here. Just code moving &
re-indentation, and re-flowing the "TRANSLATORS"
The CodingGuidelines say "When there are multiple arms to a
conditional and some of them require braces, enclose even a single
line block in braces for consistency.". Fix the code in
match_explicit() to conform.
While I'm at it change the if/else if/else in guess_ref() to use
braces. This is not
This has grown to a 7-part series for v2 (from 2 patches). This
addresse all the feedback for v1 and then some.
Ævar Arnfjörð Bjarmason (7):
remote.c: add braces in anticipation of a follow-up change
i18n: remote.c: mark error(...) messages for translation
push: improve the error shown on
The 'ewok_rlw.h' header file contains the rlw_get_run_bit() function
definition, which is marked as 'static' but not 'inline'. At least when
compiled by gcc, with the default -O2 optimization level, the function
is actually inlined and leaves no static version in the ewah_bitmap.o
and ewah_rlw.o
Add the necessary #includes and forward declarations to allow the header
file to pass the 'hdr-check' target.
Note that, since this header includes the commit-slab implementation
header file (indirectly via commit-slab.h), some of the commit-slab
inline functions (e.g contains_cache_at_peek())
Signed-off-by: Ramsay Jones
---
fetch-object.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fetch-object.h b/fetch-object.h
index d2f996d4e8..d6444caa5a 100644
--- a/fetch-object.h
+++ b/fetch-object.h
@@ -1,6 +1,8 @@
#ifndef FETCH_OBJECT_H
#define FETCH_OBJECT_H
+struct
On Fri, Oct 26, 2018 at 04:57:26PM +0900, Junio C Hamano wrote:
> * tb/filter-alternate-refs (2018-10-25) 2 commits
> (merged to 'next' on 2018-10-26 at 887a7779a3)
> + t5410: use longer path for sample script
> + Documentation/config.txt: fix typo in core.alternateRefsCommand
>
> Test fix.
>
On 26/10/2018 04:15, Carlo Arenas wrote:
> On Thu, Oct 25, 2018 at 2:09 PM Ramsay Jones
> wrote:
>> Yes, this will 'fix' the 'commit-reach.h' header (not surprising),
>> but I prefer my patch. ;-)
>
> I apologize, I joined the list recently and so might had missed a
> reroll; the merged
I have some changes to the hdr-check Makefile target in the works, but
these clean-ups don't have to be held up by those changes.
The 'fetch-object.h' patch is the same one I sent separately last time,
since it only applied on 'next' at the time. The 'ewok_rlw.h' patch is
just something I
> But this default fetch is not sufficient, as a newly fetched commit in
> the superproject could point to a commit in the submodule that is not
> in the default refspec. This is common in workflows like Gerrit's.
> When fetching a Gerrit change under review (from refs/changes/??), the
> commits
Junio C Hamano writes:
> Derrick Stolee writes:
>
>> time git log --topo-order -10 master >/dev/null
>>
>> time git log --topo-order -10 maint..master >/dev/null
>>
>> I get 0.39s for the first call and 0.01s for the second. (Note: I
>> specified "-10" to ensure we are only writing 10
On Fri, Oct 26, 2018 at 12:15 PM Jonathan Tan wrote:
[snip]
> The expected pattern.
>
> This patch looks good to me.
I'll take this as a "Reviewed-by"?
Thanks,
Stefan
Document the DWYM behavior that kicks in when pushing to an
unqualified reference.
This behavior was added in f88395ac23 ("Renaming push.", 2005-08-03)
and f8aae12034 ("push: allow unqualified dest refspecs to DWIM",
2008-04-23), and somewhat documented in bb9fca80ce ("git-push: Update
Add a test asserting that "git push origin :" where is
a branch, tag, tree or blob in refs/remotes/* doesn't DWYM when
is unqualified. This has never worked, but there's been no test for
this behavior.
See f88395ac23 ("Renaming push.", 2005-08-03), bb9fca80ce ("git-push:
Update description of
Add an advice to the recently improved error message added in
f8aae12034 ("push: allow unqualified dest refspecs to DWIM",
2008-04-23).
Now with advice.pushUnqualifiedRefName=true (on by default) we show a
hint about how to proceed:
$ ./git-push avar v2.19.0^{commit}:newbranch -n
error:
Add DWYM support for pushing a ref in refs/remotes/* when the
ref is unqualified. Now instead of erroring out we support e.g.:
$ ./git-push avar refs/remotes/origin/master:upstream-master -n
To github.com:avar/git.git
* [new branch]origin/master -> upstream-master
Improve the error message added in f8aae12034 ("push: allow
unqualified dest refspecs to DWIM", 2008-04-23), which before this
change looks like this:
$ git push avar v2.19.0^{commit}:newbranch -n
error: unable to push to unqualified destination: newbranch
The destination refspec
A follow-up change will extend this error message with the advice
facility. Doing so would make the indentation too deeply nested for
comfort. So let's split this into a helper function.
There's no changes to the wording here. Just code moving &
re-indentation, and re-flowing the "TRANSLATORS"
On Fri, Oct 26 2018, Junio C Hamano wrote:
> "Jansen, Geert" writes:
>
>> The index-pack command determines if a sha1 collision test is needed by
>> checking the existence of a loose object with the given hash. In my tests, I
>> can improve performance of “git clone” on Amazon EFS by 8x when
> Gerrit, the code review tool, has a different workflow than our mailing
> list based approach. Usually users upload changes to a Gerrit server and
> continuous integration and testing happens by bots. Sometimes however a
> user wants to checkout a change locally and look at it locally. For this
> Thanks for confirming.
>
> So even better would be to use `is_promisor_object(oid) ||
> has_object_file(oid)`, right?
>
> This is something that is probably not even needed: as I mentioned, the
> shallow commits are *expected* to be local. It should not ever happen that
> they are fetched.
On Fri, Oct 26, 2018 at 12:27 PM Ævar Arnfjörð Bjarmason
wrote:
>
> The CodingGuidelines say "When there are multiple arms to a
> conditional and some of them require braces, enclose even a single
> line block in braces for consistency.". Fix the code in
> match_explicit() to conform.
A tangent
The CodingGuidelines say "When there are multiple arms to a
conditional and some of them require braces, enclose even a single
line block in braces for consistency.". Fix the code in
match_explicit() to conform.
While I'm at it change the if/else if/else in guess_ref() to use
braces. This is not
Mark up the error(...) messages in remote.c for translation. The likes
of "unable to push to unqualified destination" are relatively big
parts of the UI, i.e. error messages shown when "git push" fails.
I don't think any of these are plumbing, an the entire test suite
passes when running the
After sending out v2 I noticed I didn't update the examples in a
couple of the commit messages, and figured I'd finish this up by
adding a patch to document how this works in the "git-push"
manpage. This behavior has never been properly documented. range-diff
with v2:
1: ca8eb6dc28 = 1:
On Fri, Oct 26, 2018 at 09:30:51AM +0200, Raphael Stolt wrote:
> Configuration for global ignore patterns in ~/.config/git/config:
>
> [core]
> excludesfile = .gitignore
>
> doesn't get looked up per default in ~/.config/git/ which might be
> considered a bug as the .gitignore file isn't
Hi Jonathan,
On Thu, 25 Oct 2018, Jonathan Tan wrote:
> > On Wed, 24 Oct 2018, Johannes Schindelin wrote:
> >
> > Coming back to my question whether there is a better way to check for
> > the presence of a local commit, I figured that I can use
> > `has_object_file()` instead of looking up and
On Sat, Oct 20, 2018 at 02:58:53PM -0400, Jeff King wrote:
> On Sat, Oct 20, 2018 at 01:14:28PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> > > I'd guess this sort of thing is pretty rare. But I wonder if we're
> > > crossing the line of trying to assume too much about what the user's
> > >
On Fri, Oct 26, 2018 at 08:43:37AM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > An easy test is:
> >
> > $ git rev-list --no-walk --exclude='*' --all --all
> > 3289ca716320457af5d2dd550b716282ad22da11
> > ...a bunch of other tip commits...
> >
> > $ git rev-parse --exclude='*'
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.
Quite a few topics have graduated
Hi Hannes,
On Thu, 25 Oct 2018, Johannes Sixt wrote:
> The sequencer instruction 'b', short for 'break', is rejected:
>
> error: invalid line 2: b
>
> The reason is that the parser expects all short commands to have
> an argument. Permit short commands without arguments.
>
> Signed-off-by:
Hi Hannes,
On Thu, 25 Oct 2018, Johannes Sixt wrote:
> Test each short command at least once. The commands changed here
> are chosen such that
I stumbled over this, and understood it only after looking at the patch.
How about this instead:
Make sure that each short command is tested
Hi Junio,
On Thu, 25 Oct 2018, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > For a long time already, we have Git's source code continuously tested via
> > Travis CI, see e.g. https://travis-ci.org/git/git/builds/421738884. It has
> > served us well, and more
Hi Junio
On 25/10/2018 09:59, Junio C Hamano wrote:
> Phillip Wood writes:
>
>> From: Phillip Wood
>>
>> Thanks to Eric for his feedback on v1. I've rerolled based on
>> that. Patches 1 & 2 are new and try to address some of the concerns
>> Eric raised, particularly the error handling for a
Configuration for global ignore patterns in ~/.config/git/config:
[core]
excludesfile = .gitignore
doesn't get looked up per default in ~/.config/git/ which might be
considered a bug as the .gitignore file isn't loaded. It's only loaded
when .gitignore is located in $HOME or explicitly
This is a resend of patchset v3 where we add another patch on top of the
existing patchset in order to document the guitool keys for `git
config`. This way, the completions script will now be able to complete
these key values as well.
Denton Liu (3):
mergetool: accept -g/--[no-]gui as arguments
Signed-off-by: Denton Liu
---
Documentation/diff-config.txt | 8
Documentation/merge-config.txt | 6 ++
2 files changed, 14 insertions(+)
diff --git a/Documentation/diff-config.txt b/Documentation/diff-config.txt
index 85bca83c3..e64d983c3 100644
---
In line with how difftool accepts a -g/--[no-]gui option, make mergetool
accept the same option in order to use the `merge.guitool` variable to
find the default mergetool instead of `merge.tool`.
Signed-off-by: Denton Liu
Signed-off-by: Anmol Mago
Signed-off-by: Brian Ho
Signed-off-by: David
Signed-off-by: Denton Liu
Signed-off-by: Anmol Mago
Signed-off-by: Brian Ho
Signed-off-by: David Lu
Signed-off-by: Ryan Wang
---
contrib/completion/git-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
On Thu, Oct 25, 2018 at 10:38:46AM -0400, Jason Cooper wrote:
> On 10/25/18 1:37 AM, Junio C Hamano wrote:
> > "lhf...@163.com" writes:
> >
> >> I have a good idea, add a file to git that is the opposite of
> >> .gitignore...,
> > Do negative patterns in .gitignore file help without inventing
>
67 matches
Mail list logo
