On Mon, Oct 24, 2016 at 6:09 PM, Junio C Hamano wrote:
>
> * sb/submodule-ignore-trailing-slash (2016-10-18) 3 commits
> . submodule--helper: normalize funny urls
> (merged to 'next' on 2016-10-11 at e37425ed17)
> + submodule: ignore trailing slash in relative url
> + submodule: ignore traili
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.
Originally I planed to start concl
On Mon, Oct 24, 2016 at 04:53:50PM -0700, Junio C Hamano wrote:
> > So how about this? It gets rid of magic number 3 and works for array
> > size that's not a power of two. And as a nice side effect it can't
> > trigger a signed overflow anymore.
>
> Looks good to me. Peff?
Any of the variant
René Scharfe writes:
> Am 24.10.2016 um 19:27 schrieb Junio C Hamano:
>> Junio C Hamano writes:
>>
I think it would be preferable to just fix it inline in each place.
>>>
>>> Yeah, probably.
>>>
>>> My initial reaction to this was
>>>
>>> char *sha1_to_hex(const unsigned char *sha1)
>>>
Instead of referencing "stash@{n}" explicitly, it can simply be
referenced as "n". Most users only reference stashes by their position
in the stash stask (what I refer to as the "index"). The syntax for the
typical stash (stash@{n}) is slightly annoying and easy to forget, and
sometimes difficult
The procedure to resolve a merge conflict typically goes like this:
- first open the file in the editor, and with the help of conflict
markers come up with a resolution.
- save the file.
- look at the output from "git diff" to see the combined diff to
double check if the resolution make
> Actually, git reads
>
> # comment
>
> as 'ignore files with name "" (4 spaces)', and then a comment.
> It does not ignore the leading whitespace.
Even not as a comment, it treats it as literally a filename with
a hash and that comment in it. However, one (usually) does not
name their fil
Am 24.10.2016 um 19:27 schrieb Junio C Hamano:
> Junio C Hamano writes:
>
>>> I think it would be preferable to just fix it inline in each place.
>>
>> Yeah, probably.
>>
>> My initial reaction to this was
>>
>> char *sha1_to_hex(const unsigned char *sha1)
>> {
>> -static int bufno;
>> +
> Note: the comments can be started away from the left margin,
> as normal in all unix-linux configuration files we know of.
> Git follows this behaviour fine.
Actually, git reads
# comment
as 'ignore files with name "" (4 spaces)', and then a comment.
It does not ignore the leading whit
The asciidoctor doc-tool stack does not always respect the 'tab = 8 spaces' rule
expectation, particularly for the Git-for-Windows generated html pages. This
follows on from the 'doc: fix merge-base ASCII art tab spacing' fix.
Use just spaces within the block of the ascii art.
All other *.txt asc
Concerning ".gitignore", experienced using git 2.10.0
Starting code using one or more spaces or tabs from the left
margin will have git reading .gitignore and ignoring(or
un-ignoring) the command-instruction.
Example: Starting .gitignore
/*
# above line is duly read. Then un-ignoring
Jeff King writes:
> If we were designing git today, it seems like a no-brainer to use zstd
> over zlib. But given backwards-compatibility issues, I'm not sure.
> 10-20% speedup on reading is awfully nice, but I don't think there's a
> good way to gracefully transition, because zlib is part of the
Junio C Hamano writes:
> Stefan Beller writes:
>
>> On Mon, Oct 24, 2016 at 7:28 AM, Yash Jain wrote:
>>> Hello,
>>> I have two accounts on github("yj291197" and "yaki29").
>>> Both the accounts have different gmail IDs("yj291...@gmail.com" and
>>> "yashjain@gmail.com" respectively) but sam
On Sun, Oct 23, 2016 at 8:07 AM, Ramsay Jones
wrote:
>
>
> On 23/10/16 00:32, Stefan Beller wrote:
>> From: Junio C Hamano
>>
>> Export attr_name_valid() function, and a helper function that
>> returns the message to be given when a given pair
>> is not a good name for an attribute.
>>
>> We cou
Stefan Beller writes:
> I looked for a platform independent way to get a thread id as a natural
> number, i.e. I want to get 1,2,3,... such that I could have just added
> list/array of attr stacks to each check, which would be the
> tuple you envision.
>
> However I think we do not really need i
Stefan Beller writes:
>> Speaking of what to and not to include in the upcoming release, we
>> do want to include Stefan's off-by-one fix to the submodule-helper,
>> but that is blocked on Windows end due to the test.
>
> I'd be happy either way, i.e. we could revert that fix and make a release?
Johannes Schindelin writes:
>> I prefer to cook it in 'next' sufficiently long to ensure that we hear
>> feedbacks from non-Windows users if there is any unexpected breakage.
>
> FWIW I am using the same patches not only on Windows but also in my Linux
> VM.
Thanks for a datapoint, but when I sa
Johannes Schindelin writes:
>> I still do not understand (note that I am not saying "I do not
>> accept"--acceptance or rejection happens after an understandable
>> explanation is given, and "do not understand" means no such
>> explanation has been given yet) your justification behind adding a
>>
> On 24 Oct 2016, at 21:22, Johannes Sixt wrote:
>
> Am 24.10.2016 um 20:03 schrieb larsxschnei...@gmail.com:
>> From: Lars Schneider
>>
>> This fixes "convert: add filter..process option" (edcc8581) on
>> Windows.
>
> Today's next falls flat on its face on Windows in t0021.15 "required proce
Eric Wong writes:
> larsxschnei...@gmail.com wrote:
>> +++ b/read-cache.c
>> @@ -156,7 +156,11 @@ void fill_stat_cache_info(struct cache_entry *ce,
>> struct stat *st)
>> static int ce_compare_data(const struct cache_entry *ce, struct stat *st)
>> {
>> int match = -1;
>> -int fd = ope
Am 24.10.2016 um 21:10 schrieb Stefan Beller:
The ease of use in our own testing suite is the feature I was talking about.
Ok, thanks for the clarification. Next steps would then be, IMO, to fix
the tests to match the future world order and mark tests that fail due
to the bug with test_expect
On Sat, Oct 22, 2016 at 10:11 AM, Junio C Hamano wrote:
>
> There isn't enough time to include this topic in the upcoming
> release within the current https://tinyurl.com/gitCal calendar,
> however, which places the final on Nov 11th.
>
> I am wondering if it makes sense to delay 2.11 by moving t
On Mon, Oct 24, 2016 at 12:07 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> Instead of having a global attr stack, attach the stack to each check.
>
> Two threads may be working on "git checkout", one "git_attr_check"
> in convert.c may be used by them to learn the EOL conversion for
> e
Am 24.10.2016 um 20:03 schrieb larsxschnei...@gmail.com:
From: Lars Schneider
This fixes "convert: add filter..process option" (edcc8581) on
Windows.
Today's next falls flat on its face on Windows in t0021.15 "required
process filter should filter data"; might it be the failure meant here?
On Mon, Oct 24, 2016 at 11:55 AM, Junio C Hamano wrote:
>
> Make that a double-asterisk. The same problem appears in an updated
> example in technical/api-gitattributes.txt doc, but the example in
> the commit log message (below) is correct.
The implementation is actually using a double pointer
On Sun, Oct 23, 2016 at 3:14 AM, Johannes Sixt wrote:
> Am 22.10.2016 um 22:46 schrieb Stefan Beller:
>>
>> I have looked into it again, and by now I think the bug is a feature,
>> actually.
>>
>> Consider this:
>>
>> git clone . super
>> git -C super submodule add ../submodule
>> # we
Stefan Beller writes:
> Instead of having a global attr stack, attach the stack to each check.
Two threads may be working on "git checkout", one "git_attr_check"
in convert.c may be used by them to learn the EOL conversion for
each path, and these threads are working in different parts of
worktr
Stefan Beller writes:
> This revamps the API of the attr subsystem to be thread safe.
> Before we had the question and its results in one struct type.
> The typical usage of the API was
>
> static struct git_attr_check *check;
>
> if (!check)
> check = git_attr_check_initl("text",
larsxschnei...@gmail.com wrote:
> +++ b/read-cache.c
> @@ -156,7 +156,11 @@ void fill_stat_cache_info(struct cache_entry *ce, struct
> stat *st)
> static int ce_compare_data(const struct cache_entry *ce, struct stat *st)
> {
> int match = -1;
> - int fd = open(ce->name, O_RDONLY);
> +
Stefan Beller writes:
> On Mon, Oct 24, 2016 at 7:28 AM, Yash Jain wrote:
>> Hello,
>> I have two accounts on github("yj291197" and "yaki29").
>> Both the accounts have different gmail IDs("yj291...@gmail.com" and
>> "yashjain@gmail.com" respectively) but same passwords.
>> I used to use git
Christian Couder writes:
> The design is similar as the previous work that introduced
> "core.untrackedCache".
>
> The new "core.splitIndex" configuration option can be either true,
> false or undefined which is the default.
>
> When it is true, the split index is created, if it does not already
larsxschnei...@gmail.com writes:
> ## Changes since v1
> * add fallbacks in case O_CLOEXEC is not available
That is a good idea.
> * rename 'git_open_noatime_cloexec' to 'git_open' (Eric, Dscho)
OK. This is the old git_open_noatime() that is meant to be used
ONLY for the files Git uses for i
This is a Github issue, so ask Github support.
Or read up on .mailmap files.
On Mon, Oct 24, 2016 at 7:28 AM, Yash Jain wrote:
> Hello,
> I have two accounts on github("yj291197" and "yaki29").
> Both the accounts have different gmail IDs("yj291...@gmail.com" and
> "yashjain@gmail.com" respe
> On 21 Oct 2016, at 12:41, Jeff King wrote:
>
> On Fri, Oct 21, 2016 at 04:43:48AM -0400, Jeff King wrote:
>
>> The obvious fix would be to send "--verbose" output to stderr, but I
>> suspect that would end up annoying for people who do:
>>
>> ./t5547-push-quarantine.sh -v | less
>>
>> to r
From: Lars Schneider
This fixes "convert: add filter..process option" (edcc8581) on
Windows.
Consider the case of a file that requires filtering and is present in
branch A but not in branch B. If A is the current HEAD and we checkout B
then the following happens:
1. ce_compare_data() opens the
From: Lars Schneider
Use the CLOEXEC flag similar to 05d1ed61 to fix leaked file descriptors.
This mini patch series is necessary to make the "ls/filter-process" topic
work properly for Windows. Right now the topic generates test failures
on Windows as reported by Dscho:
http://public-inbox.org/
From: Lars Schneider
All processes that the Git main process spawns inherit the open file
descriptors of the main process. These leaked file descriptors can
cause problems.
Use the CLOEXEC flag similar to 05d1ed61 to fix the leaked file
descriptors. Since `git_open_noatime` does not describe the
Nguyễn Thái Ngọc Duy writes:
> The index_differs_from() also takes a flag to set/clear this new
> flag instead of relying on has_ita_entries like the old 2/3.
I think that probably is a good move.
> The name ita-invisible-in-index is not perfect but I could not think
> of any better. Another n
Johannes Sixt writes:
> Am 22.10.2016 um 22:46 schrieb Stefan Beller:
>> I have looked into it again, and by now I think the bug is a feature,
>> actually.
>>
>> Consider this:
>>
>> git clone . super
>> git -C super submodule add ../submodule
>> # we thought the previous line is bugg
Junio C Hamano writes:
>> I think it would be preferable to just fix it inline in each place.
>
> Yeah, probably.
>
> My initial reaction to this was
>
> char *sha1_to_hex(const unsigned char *sha1)
> {
> - static int bufno;
> + static unsigned int bufno;
> static char hexbuffer[4
Jeff King writes:
>> > You could also write the second line like:
>> >
>> > bufno %= ARRAY_SIZE(hexbuffer);
>> >
>> > which is less magical (right now the set of buffers must be a power of
>> > 2). I expect the compiler could turn that into a bitmask itself.
>> ...
>
> I think it would be pre
Jakub Narębski writes:
>> As to fetching from two or more places as "fallback", I am
>> moderately negative to add it as a dumb feature that does nothing
>> more than "My fetch from A failed, so let's blindly try it from B".
>> I'd prefer to keep the "My fetch from A is failing" knowledge near
>>
Signed-off-by: Satoshi Yasushima
---
po/ja.po | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/po/ja.po b/po/ja.po
index f143753..510306b 100644
--- a/po/ja.po
+++ b/po/ja.po
@@ -2,16 +2,17 @@
# Copyright (C) 2005-2015 Paul Mackerras
# This file is distributed under
Hello,
I have two accounts on github("yj291197" and "yaki29").
Both the accounts have different gmail IDs("yj291...@gmail.com" and
"yashjain@gmail.com" respectively) but same passwords.
I used to use git for "yj291197" account and a few days earlier I made
this new account and used git commit t
Hi Max,
On Mon, 24 Oct 2016, Max Horn wrote:
> > On 23 Oct 2016, at 11:54, Johannes Schindelin
> > wrote:
> >
> > On Sat, 22 Oct 2016, Junio C Hamano wrote:
> >
> [...]
>
> >> There isn't enough time to include this topic in the upcoming release
> >> within the current https://tinyurl.com/gi
I'm looking into the oft-discussed idea of reducing the size of ref
advertisements by having the client say "these are the refs I'm
interested in". Let's set aside the protocol complexities for a
moment and imagine we magically have some way to communicate a set of
patterns to the server.
What sho
On Sun, Oct 23, 2016 at 07:57:30PM +0200, René Scharfe wrote:
> > > Hard to trigger, but probably even harder to diagnose once someone
> > > somehow manages to do it on some uncommon architecture.
> >
> > Indeed. If we are worried about overflow, we would also want to assume
> > that it wraps at
On Sun, Oct 23, 2016 at 01:41:25PM -0400, Aaron and Ashley Watson wrote:
> > But what's going on here? Why did we bother running rev-parse earlier if
> > we don't actually use the value of REV?
> >
> > You mentioned tweaking it to fix a broken test, and indeed, just using
> > $REV here breaks a fe
Hi Dscho,
> On 23 Oct 2016, at 11:54, Johannes Schindelin
> wrote:
>
> Hi Junio,
>
> On Sat, 22 Oct 2016, Junio C Hamano wrote:
>
[...]
>> There isn't enough time to include this topic in the upcoming
>> release within the current https://tinyurl.com/gitCal calendar,
>> however, which places
When comparing the index and the working tree to show which paths are
new, and comparing the tree recorded in the HEAD and the index to see if
committing the contents recorded in the index would result in an empty
commit, we would want the former comparison to say "these are new paths"
and the latt
The option --ita-invisible-in-index exposes the "ita_invisible_in_index"
diff flag to outside to allow easier experimentation with this new mode.
The "plan" is to make --ita-invisible-in-index default to keep consistent
behavior with 'status' and 'commit', but a bunch other commands like
'apply', '
This version splits the old 1/3 into two, with better description in
1/4. The index_differs_from() also takes a flag to set/clear this new
flag instead of relying on has_ita_entries like the old 2/3.
The name ita-invisible-in-index is not perfect but I could not think
of any better. Another name c
ita entries are dropped at tree generation phase. If the entire index
consists of just ita entries, the result would be a a commit with no
entries, which should be caught unless --allow-empty is specified. The
test "!!active_nr" is not sufficient to catch this.
Signed-off-by: Nguyễn Thái Ngọc Duy
If i-t-a entries are present and there is no change between the index
and HEAD i-t-a entries, index_differs_from() still returns "dirty, new
entries" (aka, the resulting commit is not empty), but cache-tree will
skip i-t-a entries and produce the exact same tree of current
commit.
index_differs_fr
54 matches
Mail list logo
