On 01.07.2016 05:17, Jeff King wrote:
On Thu, Jun 30, 2016 at 11:12:52AM -0700, Linus Torvalds wrote:
I do think that it's ok to cache generation numbers somewhere if there
is an algorithm that can make use of them, but every time this comes
up, it's just not been important enough to make a big
On Thu, Jun 30, 2016 at 05:14:15PM +0200, Duy Nguyen wrote:
> > So we could describe how Git handles pathspecs and pathspec magic
> > in the new manual page named gitpathspec(7), or gitpaths(7). The
> > former has the advantage of the name being identical to the entry
> > in gitglossary(7). The la
On Thu, Jun 30, 2016 at 06:39:42PM +0200, Nguyễn Thái Ngọc Duy wrote:
> Commit 76c61fb (log: decorate HEAD with branch name under
> --decorate=full, too - 2015-05-13) adds "HEAD -> branch" decoration to
> show current branch vs detached HEAD. The sign of whether HEAD is
> detached or not is "->" (
On Thu, Jun 30, 2016 at 09:38:45PM +0200, Steffen Nurpmeso wrote:
> For some time (currently with 2.9.0) know see that a single commit
> gives a longer hash than necessary, even though there is no
> ambiguity:
>
> ?0[steffen@wales ]$ git longca|
> awk 'BEGIN{l7=0;l8=0}\
> /^[[:alnum:]]{7}
On Thu, Jun 30, 2016 at 06:16:09PM +0200, Duy Nguyen wrote:
> > I've shrunk it a bit to fit in the email; my actual "long" name was much
> > larger. And the average length for the shorter ones is, too, but the
> > overall effect is the same; almost every line has a huge run of
> > whitespace. And
This should be part of every program, as otherwise users do
not get translated error messages. However, some external
commands forgot to do so (e.g., git-credential-store). This
fixes them, and eliminates the repeated code in programs
that did remember to use it.
Signed-off-by: Jeff King
---
com
This is another safety/sanity setup that should be in force
everywhere, but which we only applied in git.c. This did
catch most cases, since even external commands are typically
run via "git ..." (and the restoration applies to
sub-processes, too). But there were cases we missed, such as
somebody c
This is setup that should be done in every program for
safety, but we never got around to adding it everywhere (so
builtins benefited from the call in git.c, but any external
commands did not). Putting it in the common main() gives us
this safety everywhere.
Note that the case in daemon.c is a lit
Every program which links against libgit.a must call this
function, or risk hitting an assert() in system_path() that
checks whether we have configured argv0_path (though only
when RUNTIME_PREFIX is defined, so essentially only on
Windows).
Looking at the diff, you can see that putting it into the
There are certain startup tasks that we expect every git
process to do. In some cases this is just to improve the
quality of the program (e.g., setting up gettext()). In
others it is a requirement for using certain functions in
libgit.a (e.g., system_path() expects that you have called
git_extract_
On Fri, Jul 01, 2016 at 12:07:15AM -0400, Jeff King wrote:
> Interesting. It's failing on the assert(argv0_path) in system_path().
>
> That's part of the RUNTIME_PREFIX code which is built only on Windows,
> so this is a Windows-specific issue.
>
> I can guess the reason that argv0_path is not s
On Thursday, June 30, 2016, Jeff King wrote:
> In shell scripts it is sometimes useful to be able to read
> exactly N bytes from a pipe. Doing this portably turns out
> to be surprisingly difficult.
>
> We want a solution that:
>
> - is portable
>
> - never reads more than N bytes due to buffe
On Thu, Jun 30, 2016 at 03:24:41PM -0600, d...@ucar.edu wrote:
> Carson:part2: git push
> This application has requested the Runtime to terminate it in an unusual
> way.
> Please contact the application's support team for more information.
> A s s e r t i o n f a i l e d !
>
> P r o g r a m :
On Thu, Jun 30, 2016 at 11:12:52AM -0700, Linus Torvalds wrote:
> I do think that it's ok to cache generation numbers somewhere if there
> is an algorithm that can make use of them, but every time this comes
> up, it's just not been important enough to make a big deal and a new
> incompatible obje
On Thu, Jun 30, 2016 at 11:12:52AM -0700, Linus Torvalds wrote:
> On Thu, Jun 30, 2016 at 3:30 AM, Jakub Narębski wrote:
> >
> > P.S. Having Git ensure that committerdate (as an epoch) is greater
> > than committerdates of its parents at the commit creation time (with
> > providing warning about t
Duy Nguyen gmail.com> writes:
>
> On Thu, Jun 30, 2016 at 7:55 PM, Ben Peart gmail.com> wrote:
> > David Turner novalis.org> writes:
> >
> >>
> >> Hiding watchman behind index-helper means you need both daemons. You
> >> can't run watchman alone. Not so good. But on the other hand, 'git'
> >>
W dniu 2016-06-30 o 20:12, Linus Torvalds pisze:
> On Thu, Jun 30, 2016 at 3:30 AM, Jakub Narębski wrote:
>>
>> P.S. Having Git ensure that committerdate (as an epoch) is greater
>> than committerdates of its parents at the commit creation time (with
>> providing warning about time skew, perhaps n
Since I cannot submit a github issue, I will try here.
- Which version of Git for Windows are you using? 32-bit or 64-bit?
Include the
output of `git version` as well.
git version 2.9.0.windows.1
32-bit
- Which version of Windows are you running? 32-bit or 64-bit?
64-bit windows 7
- W
Hi,
Thanks for the clarification, it makes sense now.
Thanks,
Istvan
On 30 June 2016 at 22:57, Stefan Beller wrote:
> On Thu, Jun 30, 2016 at 6:27 AM, Istvan Zakar wrote:
>> Hello,
>>
>> Thanks for your answers. I tested it after the changes were made on
>> the git server, and it seems to
On Thu, Jun 30, 2016 at 6:27 AM, Istvan Zakar wrote:
> Hello,
>
> Thanks for your answers. I tested it after the changes were made on
> the git server, and it seems to be working. But some other issue came
> up.
>
> We have quite many submodules in our project so I did some comaprision:
>
> If I d
Signed-off-by: Philip Oakley
---
Documentation/revisions.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index 131060c..87be9c4 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/revisions.txt
@@ -246,7 +2
While there, also break out the other shorthand notations and
add a title for the revision range summary (which also appears
in git-rev-parse, so keep it mixed case).
Signed-off-by: Philip Oakley
---
Documentation/revisions.txt | 23 +--
1 file changed, 17 insertions(+), 6 de
Signed-off-by: Philip Oakley
---
Documentation/gitk.txt | 2 +-
Documentation/rev-list-options.txt | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt
index 6ade002..6c3eb15 100644
--- a/Documentation/gitk.txt
+++ b/
This is the re-roll of the po/range-doc (2016-06-27) 3 commits
The order is slightly re-arranged, and an additional patch clarifying
that ^r1 excludes r1 itself being added.
The heading have been tweaked.
Discussion: $gmane/297908
previous patch series $gmane/298223
Philip Oakley (4):
doc: us
Signed-off-by: Philip Oakley
---
Found while checking the 'symmetric difference' documentation
---
Documentation/pretty-formats.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index 29b19b9..10719e1 100644
Steffen,
Git commands generally have a 7 character minimum by default when
abbreviating hashes, even if fewer characters are still (currently)
unique. Per the documentation:
core.abbrev
Set the length object names are abbreviated to. If unspecified,
many commands abbreviate to 7
Hello, for your possible interest.
For some time (currently with 2.9.0) know see that a single commit
gives a longer hash than necessary, even though there is no
ambiguity:
?0[steffen@wales ]$ git longca|
awk 'BEGIN{l7=0;l8=0}\
/^[[:alnum:]]{7} /{++l7;next}\
/^[[:alnum:]]{8} /{++l8;pr
On Thu, Jun 30, 2016 at 7:55 PM, Ben Peart wrote:
> David Turner novalis.org> writes:
>
>>
>> Hiding watchman behind index-helper means you need both daemons. You
>> can't run watchman alone. Not so good. But on the other hand, 'git'
>> binary is not linked to watchman/json libraries, which is go
On Thu, Jun 30, 2016 at 3:30 AM, Jakub Narębski wrote:
>
> P.S. Having Git ensure that committerdate (as an epoch) is greater
> than committerdates of its parents at the commit creation time (with
> providing warning about time skew, perhaps not doing it if skew is
> too large) would be not costly
David Turner novalis.org> writes:
>
> Hiding watchman behind index-helper means you need both daemons. You
> can't run watchman alone. Not so good. But on the other hand, 'git'
> binary is not linked to watchman/json libraries, which is good for
> packaging. Core git package will run fine withou
On 29.06.16 18:14, Junio C Hamano wrote:
> tbo...@web.de writes:
>
>> From: Torsten Bögershausen
>>
>> The following didn't work as expected:
>
> Sorry for being slow (not in response but in understanding), but
> let's examine the expectation first.
Thanks for the patience.
There is one detail
Use test_i18n* functions for testing text already marked for
translation.
Signed-off-by: Vasco Almeida
---
Fix typo on v1.
Forgot to mention that tests with TTY prerequisite were skipped, I don't
know how to run them.
Notes:
Incremental update for va/i18n-even-more (merged to 'next' on 2016-
On Thu, Jun 30, 2016 at 6:39 PM, Nguyễn Thái Ngọc Duy wrote:
> Commit 76c61fb (log: decorate HEAD with branch name under
> --decorate=full, too - 2015-05-13)
.. and I got the commit wrong. It should be 51ff0f2 (log: decorate
HEAD with branch name - 2015-03-10)
adds "HEAD -> branch" decoration to
Commit 76c61fb (log: decorate HEAD with branch name under
--decorate=full, too - 2015-05-13) adds "HEAD -> branch" decoration to
show current branch vs detached HEAD. The sign of whether HEAD is
detached or not is "->" (vs ", "). It's too subtle for my poor
eyes. If color is used, we can make the b
Use test_i18n* functions for testing text already marked for
translation.
Signed-off-by: Vasco Almeida
---
Incremental update for va/i18n-even-more (merged to 'next' on 2016-06-28 at
5919dfa).
I don't know how I didn't catch this one.
t/t5541-http-push-smart.sh | 12 ++--
1 file change
On Mon, Jun 27, 2016 at 8:43 PM, Jeff King wrote:
> I tried it on my most-horrible example case, and the results were...just
> OK. Because the variable-length part of each line comes first, the
> alignment code means that the "origin/$" bit of every line gets bumped
> out. And if you have a single
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Torsten, this seems to fix the symlink problem for me. How many times
have I got similar reports from you and still managed to forget ...
t/t2028-worktree-move.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t2028-worktree-mo
On Mon, Jun 27, 2016 at 4:53 PM, Junio C Hamano wrote:
>> diff --git a/grep.c b/grep.c
>> index cb058a5..92587a8 100644
>> --- a/grep.c
>> +++ b/grep.c
>> @@ -432,15 +432,8 @@ static void compile_regexp(struct grep_pat *p, struct
>> grep_opt *opt)
>> icase = opt->regflags & REG_ICA
Hi Jakub,
Where have you been all these years? :D
On Thu, Jun 30, 2016 at 11:42 AM, Jakub Narębski wrote:
> Nowadays we have gitcli(7) manual page, but perhaps
> it would be better to create a separate manpage for issues related
> to pathspec handling (of which ":/" is only one part)
On Thu, Jun 30, 2016 at 3:06 PM, Johannes Schindelin
wrote:
> Even when NO_MMAP is empty, there might be no Unix sockets available (such
> as is the case on Windows). In any case, you really only want to skip
> these tests when index-helper is not available, so would you mind
> squashing this patc
Greetings from NASOLY STORE Supply , We are keen to placing an order for so
me items . Kindly let me know the kinds of credit card you take for payment
.
Will be waiting to read back from you via : allenlescot...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe git" in
the b
On 06/23/2016 07:10 PM, Michael Haggerty wrote:
> On 06/17/2016 06:09 PM, Stefan Beller wrote:
>> I think before spending more time on discussing and implementing new
>> (hopefully better) heuristics, I'd want to step back and try to be a bit more
>> systematic, i.e. I'll want to collect lots of te
Hello,
Thanks for your answers. I tested it after the changes were made on
the git server, and it seems to be working. But some other issue came
up.
We have quite many submodules in our project so I did some comaprision:
If I do a clone with these parameters:
--jobs 20 --recurse-submodules
The
Hi Dave,
On Sun, 26 Jun 2016, David Turner wrote:
> diff --git a/t/t7900-index-helper.sh b/t/t7900-index-helper.sh
> new file mode 100755
> index 000..114c112
> --- /dev/null
> +++ b/t/t7900-index-helper.sh
> @@ -0,0 +1,23 @@
> +#!/bin/sh
> +#
> +# Copyright (c) 2016, Twitter, Inc
> +#
> +
>
Signed-off-by: Charles Bailey
---
t/t7810-grep.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t7810-grep.sh b/t/t7810-grep.sh
index 1e72971..c4302ed 100755
--- a/t/t7810-grep.sh
+++ b/t/t7810-grep.sh
@@ -353,7 +353,7 @@ test_expect_success 'grep -l -C' '
cat >expected <
So I've got back around to this topic again.
I've applied fixes to the tests as suggested by Eric and Junio.
I came up with a test case that demonstrates a difference between the
additional fix that Duy suggested and the alternative that Junio
suggested.
I've kept Duy's fix because I think it ma
Signed-off-by: Charles Bailey
---
t/t7810-grep.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t7810-grep.sh b/t/t7810-grep.sh
index c4302ed..6e6eaa4 100755
--- a/t/t7810-grep.sh
+++ b/t/t7810-grep.sh
@@ -175,7 +175,7 @@ do
test_expect_success "grep -c $L (no /d
From: Charles Bailey
This reverts commit 4d5520053 (grep: make it clear i-t-a entries are
ignored, 2015-12-27) and adds an alternative fix to maintain the -L
--cached behavior.
4d5520053 caused 'git grep' to no longer find matches in new files in
the working tree where the corresponding index en
W dniu 2016-06-30 o 08:22, Jeff King pisze:
> On Wed, Jun 29, 2016 at 12:48:33PM +0100, Laszlo Papp wrote:
>
>> Old releases are maintained with important bug fixes or even new features
>> in our case. It sometimes means that we need to cherry-pick commits across
>> branches, like from master to a
W dniu 2016-06-30 o 00:00, Jeff King pisze:
> On Wed, Jun 29, 2016 at 11:49:35PM +0200, Jakub Narębski wrote:
>
>>> So this is the ideal case for generation numbers (the worst cases are
>>> when the things you are looking for are in branchy, close history where
>>> the generation numbers don't tel
On Wed, Jun 29, 2016 at 10:01 PM, Eric Wong wrote:
> Christian Couder wrote:
>> Design discussion about performance
>> ~~~
>>
>> Yeah, it is not efficient to fork/exec a command to just read or write
>> one object to or from the external ODB. Batch calls and/or usi
On Tue, Jun 28, 2016 at 11:39 PM, Junio C Hamano wrote:
> Christian Couder writes:
>
>> @@ -98,8 +97,7 @@ int write_or_whine_pipe(int fd, const void *buf, size_t
>> count, const char *msg)
>> int write_or_whine(int fd, const void *buf, size_t count, const char *msg)
>> {
>> if (write_in_
Hi Ramsay,
On Thu, Jun 30, 2016 at 3:47 AM, Ramsay Jones
wrote:
>
> Hi Christian,
>
> If you need to re-roll your 'cc/apply-am' branch, could you please
> squash this into the relevant patch. Commit 95a3b0ba ("apply: move
> libified code from builtin/apply.c to apply.{c,h}", 22-04-2016)
> removed
W dniu 2016-06-29 o 23:28, Junio C Hamano pisze:
> Jakub Narębski writes:
>
>> But I think it is not the best place to keep this documentation.
>
> All true. In case it was not obvious, I didn't mean to say "Here
> you find the information, shut up." It was "here is a pointer if
> you didn't f
On Thu, Jun 30, 2016 at 10:42:37AM +0200, Johannes Schindelin wrote:
> > > The vast majority of error messages in Git's source code which report a
> > > bug use the convention to prefix the message with "BUG:".
> >
> > Good thing to do.
> >
> > But if we were to review and apply a 200+ line patc
The ustar format only has room for 11 (or 12, depending on
some implementations) octal digits for the size and mtime of
each file. For values larger than this, we have to add pax
extended headers to specify the real data, and git does not
yet know how to do so.
Before fixing that, let's start off
On Thu, Jun 30, 2016 at 05:06:14AM -0400, Jeff King wrote:
> The one thing that isn't fixed is the use of "141" to test for sigpipe
> death. That should use test_match_signal, but that topic just got
> re-rolled, too.
And here's what the patch for that looks like (which can be applied if
this top
In shell scripts it is sometimes useful to be able to read
exactly N bytes from a pipe. Doing this portably turns out
to be surprisingly difficult.
We want a solution that:
- is portable
- never reads more than N bytes due to buffering (which
would mean those bytes are not available to t
The ustar format represents timestamps as seconds since the
epoch, but only has room to store 11 octal digits. To
express anything larger, we need to use an extended header.
This is exactly the same case we fixed for the size field in
the previous commit, and the solution here follows the same
pat
The ustar format has a fixed-length field for the size of
each file entry which is supposed to contain up to 11 bytes
of octal-formatted data plus a NUL or space terminator.
These means that the largest size we can represent is
0777, or 1 byte short of 8GB. The correct solution
for a large
We never do any error checks, and so never return anything
but "0". Let's just drop this to simplify the code.
Signed-off-by: Jeff King
---
archive-tar.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/archive-tar.c b/archive-tar.c
index d671bc3..7ea4e90 100644
--
This is a re-roll of the jk/big-and-future-archive-tar topic. It
addresses all but one of the review comments, and I hope should be
pretty polished.
The changes are:
- the dependency on bunzip2 is dropped; instead, we just provide a
partial object for the 64GB blob. See the first commit mes
Hi Hannes,
On Thu, 30 Jun 2016, Johannes Sixt wrote:
> Am 29.06.2016 um 13:36 schrieb Johannes Schindelin:
> > @@ -955,9 +955,8 @@ static struct merge_file_info merge_file_1(struct
> > merge_options *o,
> >
> > if (!sha_eq(a->sha1, b->sha1))
> > result.clean = 0;
Hi Junio,
On Wed, 29 Jun 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > From: Junio C Hamano
>
> Did I write this thing?
Yes, you did. It was db05d6194d3f9ea9e64163944961d5f6e85302be as part of
pu@{2016-06-15}.
> Having two sets of numbers that illustrated that this is not
Hi Junio,
On Wed, 29 Jun 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > The vast majority of error messages in Git's source code which report a
> > bug use the convention to prefix the message with "BUG:".
>
> Good thing to do.
>
> But if we were to review and apply a 200+ li
Hi Eric,
On Wed, 29 Jun 2016, Eric Sunshine wrote:
> On Wed, Jun 29, 2016 at 7:36 AM, Johannes Schindelin
> wrote:
> > The vast majority of error messages in Git's source code which report a
> > bug use the convention to prefix the message with "BUG:".
> > [...]
> > Signed-off-by: Johannes Schin
Hi Junio,
On Wed, 29 Jun 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > To keep the time t3404 requires short (in this developer's Windows
> > setup, this single test already takes a painful 8 minutes to pass),
> > we avoid a full-blown GPG test and cop out by verifying the mes
Hi Junio,
On Wed, 29 Jun 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > On Wed, 29 Jun 2016, Junio C Hamano wrote:
> >
> >> Johannes Schindelin writes:
> >>
> >> > The past tense of "to run" is "run", not "ran".
> >>
> >> Actually, past tense of the verb "to run" is "ran" ;-
On Wed, Jun 29, 2016 at 07:41:36AM +0200, Johannes Sixt wrote:
> Am 29.06.2016 um 03:43 schrieb Jeff King:
> > Another is to just put the posix/ksh schemes into the helper function,
> > and let Windows people sort it out later if they want to.
>
> Let's do this.
OK, here's a replacement for the
69 matches
Mail list logo
