Greetings To You,
My Name is Mavis wanczyk , the winner of the Power ball jackpot of $ $758.7
million in the AUGUST 24, 2017, My jackpot was a gift from God to me hence my
Entire family/foundation has AGREED to do this. My foundation is donating
$500,000.00USD to you. please contac maviswanczy
Thanks for following up. A few minor comments:
On Tue, Sep 05, 2017 at 04:57:24PM -0400, Ross Kabus wrote:
> From: Ross Kabus
> Date: Tue, 5 Sep 2017 13:54:52 -0400
> Subject: [PATCH] commit-tree: don't append a newline with -F
Usually you'd just omit these in favor of the email headers (and re
Hi,
On 7 September 2017 at 13:27, 夏大雨 wrote:
> I want to merge branch a to branch b so I rename branch b to a&b, but
> when I push a&b to remote repo, '&' is took as & operator for shell,
> and git push fails. So it would be better that branch name support &
> character for me.
Have you tried qu
On Thu, Sep 07, 2017 at 04:51:12AM +0900, Junio C Hamano wrote:
> > diff --git a/builtin/shortlog.c b/builtin/shortlog.c
> > index 43c4799ea9..48af16c681 100644
> > --- a/builtin/shortlog.c
> > +++ b/builtin/shortlog.c
> > @@ -50,66 +50,67 @@ static int compare_by_list(const void *a1, const void
I want to merge branch a to branch b so I rename branch b to a&b, but
when I push a&b to remote repo, '&' is took as & operator for shell,
and git push fails. So it would be better that branch name support &
character for me.
On Wed, Sep 6, 2017 at 12:58 PM, Junio C Hamano wrote:
> The current gitlink implementation records only the "what commit
> from the subproject history is to be checked out at this path?" and
> nothing else, by storing a single SHA-1 that happens to be the name
> of the commit object (but the supe
Stefan Beller writes:
> On the ref to store the push certs:
> (a) Currently the ref points at the blob, I wonder if we'd rather want to
> point at a commit? (Then we can build up a history of
> push certs, instead of relying on the reflog to show all
> push certs. Also the gc issue mi
Nicolas Morey-Chaisemartin writes:
>> If it is not the latter, perhaps we may want to flip the order of
>> config parsing and option parsing around? That will allow us to fix
>> the handling of autostash thing to use only one variable, and also
>> fix your patch to do the right thing.
>
> I see
Martin Ågren writes:
> The function was deprecated in commit 89576613 ("treewide: deprecate
> git_config_maybe_bool, use git_parse_maybe_bool", 2017-08-07) and has no
> users.
>
> Signed-off-by: Martin Ågren
> ---
Thanks. Will queue.
On Wed, Sep 06, 2017 at 08:12:24PM +0200, Martin Ågren wrote:
> On 5 September 2017 at 23:26, Junio C Hamano wrote:
> > Jeff King writes:
> >
> >> I noticed the HEAD funniness, too, when looking at this earlier. I agree
> >> with Junio that it's not quite consistent with the general rule of
> >>
Kevin Willford writes:
> The code was using two string_lists, one for the directories and
> one for the files. The code never checks the lists independently
> so we should be able to only use one list. The string_list also
> is a O(log n) for lookup and insertion. Switching this to use a
> has
Stefan Beller writes:
>> I also thought that we were hunting calls of cmd_foo() from outside
>> the git.c command dispatcher as grave errors and want to clean up
>> the codebase to get rid of them.
>
> ... but I did not account for this fact. (I was not aware of these being
> called grave errors,
Stefan Beller writes:
>> Ahh, I was an idiot (call it vacation-induced-brain-disfunction). I
>> forgot about 0f1930c5 ("parse-options: allow positivation of options
>> starting, with no-", 2012-02-25), which may have already made your
>> new use of "--no-verify" in builtin/merge.c and existing o
The code was using two string_lists, one for the directories and
one for the files. The code never checks the lists independently
so we should be able to only use one list. The string_list also
is a O(log n) for lookup and insertion. Switching this to use a
hashmap will give O(1) which will save
On Tue, Sep 5, 2017 at 6:57 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> Junio writes:
>>> I didn't check how "merge --continue" is implemented, but we need to
>>> behave exactly the same way over there, too. Making sure that it is
>>> a case in t7504 may be a good idea, in addition to
On Wed, Sep 6, 2017 at 1:01 PM, Junio C Hamano wrote:
> Jonathan Nieder writes:
>
>> Signed-off-by: Jonathan Nieder
>> Signed-off-by: Stefan Beller
>> ---
>> sha1_file.c | 16 +---
>> 1 file changed, 9 insertions(+), 7 deletions(-)
>>
>> diff --git a/sha1_file.c b/sha1_file.c
>> in
On Tue, Sep 5, 2017 at 8:16 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Stefan Beller writes:
>>
>>> This patch disallows all no- options, but we could be more open and allow
>>> --no-options that have the NO_NEG bit set.
>>
>> "--no-foo" that does not take "--foo" is perhaps OK
On Wed, Sep 6, 2017 at 2:39 AM, Shikher Verma wrote:
> Currently, git only stores push certificates if there is a receive hook
> present. This may violate the principle of least surprise (e.g., I
> pushed with --signed, and I don't see anything in upstream).
> Additionally, push certificates could
On Wed, Sep 6, 2017 at 2:26 AM, Junio C Hamano wrote:
> Thomas Gummerer writes:
>
>> gcc on arch linux (version 7.1.1) warns that a NULL argument is passed
>> as the second parameter of memcpy.
>>
>> In file included from refs.c:5:0:
>> refs.c: In function ‘ref_transaction_verify’:
>> cache.h:948
On Tue, Sep 5, 2017 at 8:37 PM, Kevin Willford wrote:
>> From: Thomas Gummerer [mailto:t.gumme...@gmail.com]
>> Sent: Monday, September 4, 2017 4:58 PM
[..]
>> I unfortunately didn't have more time to dig so
>>
>> > As ce->name is however not nul terminated
>>
>> just comes from my memory and fr
Jonathan Nieder writes:
> Signed-off-by: Jonathan Nieder
> Signed-off-by: Stefan Beller
> ---
> sha1_file.c | 16 +---
> 1 file changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/sha1_file.c b/sha1_file.c
> index e7c86e5363..b854cad970 100644
> --- a/sha1_file.c
> +++ b/sha1
Robert Dailey writes:
> The gitmodules documentation[1] states that the .gitmodules file is at
> the root. However, it would be nice if this could be supported in any
> directory similar to how .gitignore works.
I have a mild suspicion that there would be a huge impedance
mismatch between what g
Rene Scharfe writes:
> Signed-off-by: Rene Scharfe
> ---
> builtin/clone.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/builtin/clone.c b/builtin/clone.c
> index 8d11b570a1..dbddd98f80 100644
> --- a/builtin/clone.c
> +++ b/builtin/clone.c
> @@ -487,28 +487,28 @@ N_(
Martin Ågren writes:
> Junio: The topic is in pu as ma/split-symref-update-fix. Re-roll or new
> topic or as a separate "patch 4/3" for you to place on top, any
> preference?
Until a topic hits 'next', you solely own it and it is mostly up to
you how to go about improving it. My preference woul
Rene Scharfe writes:
> Release allocated strbufs in functions that are at least potentionally
> library-like; cmd_*() functions are out of scope because the process
> ends with them and the OS cleans up for us anyway. The patches are
> split by function and were generated with --function-context
Rene Scharfe writes:
> If format_tracking_info() returns 0 only if it didn't touch its strbuf
> parameter, so it's OK to exit early in that case. Clean up sb in the
> other case.
These two "if"s confuse me; perhaps the first one is not needed?
Jeff King writes:
> As an aside, the mru code could probably be simplified a bit by reusing
> the list implementation from list.h (both were added around the same
> time, and it wasn't worth creating a dependency then, but I think list.h
> is useful and here to stay at this point).
>
> It's defin
Rene Scharfe writes:
> Signed-off-by: Rene Scharfe
> ---
> builtin/shortlog.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/builtin/shortlog.c b/builtin/shortlog.c
> index 43c4799ea9..48af16c681 100644
> --- a/builtin/shortlog.c
> +++ b/builtin/shortlog.c
> @@ -50,66 +50,67 @@ static
Dear Friend,
It's my pleasure to write you today, I am Mr. Patrick Joseph, I work
with the African Development Bank, I wish to place your name as the
beneficiary to $17.5 million US dollars only due to the death of the
depositor who died years ago along with her family.
However, I assure you that
On Wed, Sep 6, 2017 at 6:53 AM, Robert Dailey wrote:
> The gitmodules documentation[1] states that the .gitmodules file is at
> the root. However, it would be nice if this could be supported in any
> directory similar to how .gitignore works. Right now git-subrepo does
> not support submodules ins
On 5 September 2017 at 23:26, Junio C Hamano wrote:
> Jeff King writes:
>
>> I noticed the HEAD funniness, too, when looking at this earlier. I agree
>> with Junio that it's not quite consistent with the general rule of
>> "string list items point to their refnames", but I don't think it
>> matte
On Wed, Sep 6, 2017 at 4:19 AM, Duy Nguyen wrote:
>
> So, probably no worktree iterator (yet).
Ok, thanks for considering it.
On Wed, Sep 6, 2017 at 4:08 AM, Duy Nguyen wrote:
> On Thu, Aug 24, 2017 at 2:14 AM, Stefan Beller wrote:
>> On Wed, Aug 23, 2017 at 5:36 AM, Nguyễn Thái Ngọc Duy
>> wrote:
>>> The "submodule" argument in this function is a path, which can have
>>> either '/' or '\\' as a separator. Use is_dir_
On 5 September 2017 at 15:05, Jeff King wrote:
> 1. It can be compiled conditionally. There's no need in
> normal runs to do this free(), and it just wastes time.
> By using a macro, we can get the benefit for leak-check
> builds with zero cost for normal builds (this patch
>
From: Jeff Hostetler
Version 2 addresses the comments and suggestions on version 1.
It removes the explicit disable/enable rehash and just relies
on the state of hashmap counting.
It changes the declaration of the hashmap_get_size() to be
static to avoid issues seen on some compilers.
It uses BUG
From: Jeff Hostetler
This is to address concerns raised by ThreadSanitizer on the mailing list
about threaded unprotected R/W access to map.size with my previous "disallow
rehash" change (0607e10009ee4e37cb49b4cec8d28a9dda1656a4).
See:
https://public-inbox.org/git/adb37b70139fd1e2bac18bfd22c8b96
On 9/5/2017 9:24 PM, Junio C Hamano wrote:
Jeff Hostetler writes:
From: Jeff Hostetler
I feel somewhat stupid to say this, especially after seeing many
people applaud this patch, but I do not seem to be able to even
build Git with this patch. I am getting:
common-main.o: In functi
On Wed, Sep 6, 2017 at 1:53 PM, Jeff King wrote:
> [...]
> Subject: [PATCH] rev-parse: don't trim bisect refnames
>
> Using for_each_ref_in() with a full refname has always been
> a questionable practice, but it became an error with
> b9c8e7f2fb (prefix_ref_iterator: don't trim too much,
> 2017-05
Hello dear,
How are you? I know my email may come to you as a surprise but I have contacted
you for discussions for an investment plan which I want to be established in
your country. I need your urgent response for further discussion on the subject.
Yours sincerely,
Mr Saif Asmat Hashim
The gitmodules documentation[1] states that the .gitmodules file is at
the root. However, it would be nice if this could be supported in any
directory similar to how .gitignore works. Right now git-subrepo does
not support submodules inside of a subrepo[2] (I suspect subtrees
would have the same pr
On Wed, Sep 06, 2017 at 01:59:31PM +0200, Michael J Gruber wrote:
> BTW, there's more fallout from those name-rev changes: In connection
> with that other thread about surprising describe results for emacs.git I
> noticed that I can easily get "git name-rev --stdin" to segfault there.
> As easy as
On Wed, Sep 06, 2017 at 03:23:42PM +0200, Johannes Schindelin wrote:
> On Wed, 6 Sep 2017, Jeff King wrote:
>
> > I find the diff hard to read because it shows the opposite of what I did
> > (moving the big block to its own function, rather than moving the little
> > bits to a new copy of the fun
Hi Peff,
On Wed, 6 Sep 2017, Jeff King wrote:
> I find the diff hard to read because it shows the opposite of what I did
> (moving the big block to its own function, rather than moving the little
> bits to a new copy of the function).
I guess --patience would have made it slightly more readable.
We wish to let you know about the donation our foundation is making
you have been given the sum of $2, 500,000 for the purpose of social
work in your community.
I am writing on behalf of foundation, that raises money for child
medical bills. Each year we hold a number of fun family fundraising
eve
On Wed, Sep 06, 2017 at 12:59:46PM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > In the long run we may want to drop the "tempfiles must remain forever"
> > rule. This is certainly not the first time it has caused confusion or
> > leaks. And I don't think it's a fundamental issue, just
On Tue, Sep 05, 2017 at 10:41:51PM +0200, Martin Ågren wrote:
> FWIW, this series (combined with the other series you mentioned) makes
> t and t0001 pass for me with gcc/clang. There are actually some
> leaks in t, they're just silently being reported to stderr, since
> the exit statuses f
When the RUNTIME_PREFIX compile-time knob isn't set, we
never look at the argv0_path we extract. We can push its
declaration inside the #ifdef to make it more clear that the
extract code is effectively a noop.
This also un-confuses leak-checking of the argv0_path
variable when RUNTIME_PREFIX isn't
The system_path() function has an #ifdef in the middle of
it. Let's move the conditional logic into a sub-function.
This isolates it more, which will make it easier to change
and add to.
Signed-off-by: Jeff King
---
I find the diff hard to read because it shows the opposite of what I did
(moving
On Wed, Sep 06, 2017 at 10:42:07AM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > In fact, the whole extract_argv0_path thing is pointless without
> > RUNTIME_PREFIX. So I think one reasonable fix is just:
> [...]
> Yeah, I kind of like this (I would have reduced the ifdef noise by
> lea
Junio C Hamano venit, vidit, dixit 06.09.2017 05:35:
> Michael J Gruber writes:
>
>> Earlier, dddbad728c ("timestamp_t: a new data type for timestamps",
>> 2017-04-26) changed several types to timestamp_t.
>>
>> 5589e87fd8 ("name-rev: change a "long" variable to timestamp_t",
>> 2017-05-20) clean
On Tue, Sep 05, 2017 at 03:13:41PM -0700, Linus Torvalds wrote:
> On Tue, Sep 5, 2017 at 3:03 PM, Jeff King wrote:
> >
> > This probably fixes it:
>
> Yup. Thanks.
Thanks for confirming. Here it is with a commit message and test.
-- >8 --
Subject: [PATCH] rev-parse: don't trim bisect refnames
On Fri, Aug 25, 2017 at 4:52 AM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
> ... which does what?
>
> Unlike refs_for_each_ref() and friends, this does not iterate.
> It just uses the same function signature to make a single call
> of fn on the "HEAD" ref.
>
> Did I capt
On Thu, Aug 24, 2017 at 2:54 AM, Stefan Beller wrote:
>> +int other_head_refs(each_ref_fn fn, void *cb_data)
>> +{
>> + struct worktree **worktrees, **p;
>> + int ret = 0;
>> +
>> + worktrees = get_worktrees(0);
>> + for (p = worktrees; *p; p++) {
>> + struct
On Thu, Aug 24, 2017 at 2:14 AM, Stefan Beller wrote:
> On Wed, Aug 23, 2017 at 5:36 AM, Nguyễn Thái Ngọc Duy
> wrote:
>> The "submodule" argument in this function is a path, which can have
>> either '/' or '\\' as a separator. Use is_dir_sep() to support both.
>>
>> Noticed-by: Johannes Sixt
>
On Fri, Aug 25, 2017 at 6:21 PM, Michael J Gruber wrote:
> I suggest we think about the UI exposure a bit when it
> comes to including all heads or naming options, though:
>
> * HEAD is "the current head"
> * refs/heads is where all local branch heads are
>
> * --branches is the rev-list/log optio
receive-pack: store push cert irrespective of hook
Push certificates are being saved to disk only when hook was
attached on the server side, which may complicate tooling and
interaction with the certificates. Add write_push_cert_sha1() to
save push cert to disk regardless of this.
Signed-off-by:
Currently, git only stores push certificates if there is a receive hook
present. This may violate the principle of least surprise (e.g., I
pushed with --signed, and I don't see anything in upstream).
Additionally, push certificates could be more versatile if they are not
tightly bound to git ho
path: Add named reference to push cert
builtin/receive-pack: update named push cert ref
Push certificates are "detached" objects on the git objects tree.
Add a named reference so the latest push certificate can be easily
fetched, verified and stored for later use. This eases tooling
around the pus
"git pull" supports a --recurse-submodules option but does not parse the
submodule.recurse configuration item to set the default for that option.
Meanwhile "git fetch" does support submodule.recurse, producing
confusing behavior: when submodule.recurse is enabled, "git pull"
recursively fetches sub
59 matches
Mail list logo
