On Thu, Oct 19, 2017 at 02:30:08PM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > it does. It just adjusts our "end pointer" to point to the last valid
> > character in the string (rather than one past), which seems to be the
> > convention that those loops (and
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.
2.15-rc2 has slipped and will be
Compliment of the day,
How is your day. I am Mrs. Siti Zakaiah from Malaysia, I am writing to
let know you that
I am a widow and got some amount of $5.3M which was left by my late
husband and the problem now is that my late husband family wants to
deprived me of this fund.
I will like you to
On Thu, Oct 19, 2017 at 02:32:04PM +0900, Junio C Hamano wrote:
> > Yeah I am not sure if I like this comparison at the beginning of the
> > function:
> >
> > static int next_byte(const char **cp, const char **endp,
> > const struct diff_options *diffopt)
> >
Junio C Hamano writes:
> Jeff King writes:
>
>> it does. It just adjusts our "end pointer" to point to the last valid
>> character in the string (rather than one past), which seems to be the
>> convention that those loops (and next_byte) expect.
>
> Yeah I am
Jeff King writes:
> it does. It just adjusts our "end pointer" to point to the last valid
> character in the string (rather than one past), which seems to be the
> convention that those loops (and next_byte) expect.
Yeah I am not sure if I like this comparison at the beginning of
On Thu, Oct 19, 2017 at 01:04:59AM -0400, Jeff King wrote:
> So. That leaves me with:
>
> - I'm unclear on whether next_byte() is meant to return that trailing
> NUL or not. I don't think it causes any bugs, but it certainly
> confused me for a function to take a cp/endp pair of
Ben Peart writes:
> There is code in post_read_index_from() to catch out of order entries
> when reading an index file. This order verification is ~13% of the cost
> of every call to read_index_from().
I find this a bit over-generalized claim---wouldn't the overhead
Good day
My name is Lutz Albrecht, an attorney, I have searched for several years to
locate any possible relative of a late client of mine who died intestate but
left a huge financial estate. I am contacting you because you have the same
last name to present you as the beneficiary of the
On Thu, Oct 12, 2017 at 08:20:57PM -0400, Jeff King wrote:
> On Thu, Oct 12, 2017 at 08:18:37PM -0400, Jeff King wrote:
>
> > Fix this by entering the conditional only when we actually
> > see whitespace. We can apply this also to the
> > IGNORE_WHITESPACE change. That code path isn't buggy
> >
Jonathan Nieder writes:
> Or, to capture the other changes being made at the same time:
>
> config doc: clarify "git config --path" example
>
> Thanks for working on this.
Yup. I'll queue with the above subject; all the suggestions in your
message were sensible, so
On Thu, Oct 19, 2017 at 09:41:29AM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > Tangential to your patch, I also wondered why we did not pass
> > RESOLVE_REF_READING to resolve_ref_unsafe(). I think the answer is that
> > for symref lookups, we normally don't pass it so
org...@gmail.com writes:
> From: Orgad Shaneh
>
> Commit 7550424804 (name-rev: include taggerdate in considering the best
> name) introduced a bug in name-rev.
> ...
> builtin/name-rev.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
Can you update a test to
Jeff King writes:
> Tangential to your patch, I also wondered why we did not pass
> RESOLVE_REF_READING to resolve_ref_unsafe(). I think the answer is that
> for symref lookups, we normally don't pass it so that we can handle
> dangling symrefs. Of course we _just_ wrote HEAD
Brandon Williams writes:
> On 10/16, Heiko Voigt wrote:
>> To make extending this logic later easier.
>
> This makes things so much clearer, thanks!
I agree that it is clear to see what the code after the patch does,
but the code before the patch is so convoluted to follow
Stefan Beller writes:
>> but if we already have a submodule with that name (the most likely
>> explanation for its existence is because it started its life there
>> and then later moved), and the submodule is bound to a different
>> path, then that is a different submodule.
Hi Nathan et al,
PAYRE NATHAN p1508475 wrote:
> From: PAYRE NATHAN p1508475
nit: this 'From' line doesn't match any of the authors with sign-offs
below. I'm wondering if the authorship of the commit (from "git
commit --author" or git's "user.name" / "user.email"
On Wed, Oct 18, 2017 at 12:58 PM, Kevin Daudt wrote:
> On Sat, Sep 23, 2017 at 07:55:56PM +, Christian Couder wrote:
>> diff --git a/t/perf/run b/t/perf/run
>> index beb4acc0e428d..1e7c2a59e45dc 100755
>> --- a/t/perf/run
>> +++ b/t/perf/run
>> @@ -2,9 +2,14 @@
>>
>> case
On Wed, Oct 18, 2017 at 07:55:31PM +, Guillaume Castagnino wrote:
> From: Guillaume Castagnino
> [...]
Stefan raised a few meta issues, all of which I agree with. But I had
some questions about the patch itself:
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
>
Change the word "bla" to "section.variable", "bla" is a placeholder
for a variable name and it wasn't clear for everyone. This change
clarify it.
Change the appearance of 'git config section.variable {tilde}/' to
`git config section.variable ~/` to harmonize it with the rest of the
file, this is
On Wed, Oct 18, 2017 at 12:55 PM, Guillaume Castagnino
wrote:
> From: Guillaume Castagnino
>
> as stated in comment in
> https://github.com/git/git/commit/46a13857fc036b54ac2ddd0a218e5cc171aa7bd9#diff-00703a794a540acf45e225abd6aeda3b
> the referenced
On Wed, Oct 18, 2017 at 12:42 PM, 小川恭史 wrote:
> I wanna learn how daily git command works when I run specific git command.
1. Obtain the sources and compile Git yourself
(git clone https://kernel.googlesource.com/pub/scm/git/git
cd git && make && make install).
On 10/19, 小川恭史 wrote:
> I wanna learn how daily git command works when I run specific git command.
>
> I wanna know which function is actually called then, how variables
> changes its value, and how some object is stored into database.
>
> How can I debug git source code interactively with
From: Guillaume Castagnino
as stated in comment in
https://github.com/git/git/commit/46a13857fc036b54ac2ddd0a218e5cc171aa7bd9#diff-00703a794a540acf45e225abd6aeda3b
the referenced commit is broken when using ACL and not basic UNIX rights.
this commit handle ACL too
---
I wanna learn how daily git command works when I run specific git command.
I wanna know which function is actually called then, how variables
changes its value, and how some object is stored into database.
How can I debug git source code interactively with debugger like gdb?
On Wed, Oct 18, 2017 at 08:00:43PM +0300, Andrey Okoshkin wrote:
> Add check of the resolved HEAD reference while printing of a commit summary.
> resolve_ref_unsafe() may return NULL pointer if underlying calls of lstat() or
> open() fail in files_read_raw_ref().
> Such situation can be caused by
On 10/16, Heiko Voigt wrote:
> To make extending this logic later easier.
This makes things so much clearer, thanks!
>
> Signed-off-by: Heiko Voigt
> ---
> submodule.c | 74
> ++---
> 1 file changed, 37 insertions(+),
On Tue, Oct 17, 2017 at 5:03 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>>> + /* make sure name does not collide with existing
>>> one */
>>> + submodule = submodule_from_name(commit_oid, name);
>>> +
Hello,
We recently visited your website and we are interested in your models, We will
like to make an order from your list of products. However, we would like to see
your company's latest catalogs with the; minimum order quantity, delivery
time/FOB, payment terms etc. Official order placement
Add check of the resolved HEAD reference while printing of a commit summary.
resolve_ref_unsafe() may return NULL pointer if underlying calls of lstat() or
open() fail in files_read_raw_ref().
Such situation can be caused by race: file becomes inaccessible to this moment.
Signed-off-by: Andrey
There is code in post_read_index_from() to catch out of order entries
when reading an index file. This order verification is ~13% of the cost
of every call to read_index_from().
Update check_ce_order() so that it skips this verification unless the
"verify_ce_order" global variable is set.
Teach
Suppose the tip commit of my branch contains changes to multiple
files. If I want to revert all changes in one file from that commit, I
have two options that I know of:
$ git reset @^ -- foo.txt
$ git commit --amend --no-edit
$ git checkout -- foo.txt
Or:
$ git checkout @^ -- foo.txt
$ git
From: Orgad Shaneh
Commit 7550424804 (name-rev: include taggerdate in considering the best
name) introduced a bug in name-rev.
If a repository has both annotated and non-annotated tags, annotated
tag will always win, even if it was created decades after the commit.
Consider a
On Sat, Sep 23, 2017 at 07:55:56PM +, Christian Couder wrote:
> It is error prone and tiring to use many long environment
> variables to give parameters to the 'run' script.
>
> Let's make it easy to store some parameters in a config
> file and to pass them to the run script.
>
> The
Hi,
There was an issue with lightweight tags that was supposed to be fixed
in Git 2.14 (by branch jc/name-rev-lw-tag).
I also proposed a patch[1], but that was too late, after the other fix
was already in master.
Anyway, I still have the same issue with git 2.14.2.windows.3.
My repository has
35 matches
Mail list logo