Apologies! I am a military woman ,seeking your kind assistance.
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Phil Hord writes:
> stash-store cannot create a new stash with the same ref as stash@{0}. No
> error is returned even though no new stash log is created. Add a failing
> test to track.
>
> Signed-off-by: Phil Hord
> ---
Sorry, I lost track. Where is
Jeff King writes:
> Yeah, I really would have expected this to work, too. Should we be
> taking the merge base of the set of "new" commits, and using that as the
> true "new"?
> ...
> So maybe that's not workable.
>
> (I've never really dug into the bisect algorithm, and this is
Max Kirillov writes:
> http-backend reads whole input until EOF. However, the RFC 3875 specifies
> that a script must read only as many bytes as specified by CONTENT_LENGTH
> environment variable. This causes hang under IIS/Windows, for example.
>
> Make http-backend read only
Stefan Beller writes:
> On Tue, Nov 21, 2017 at 11:55 PM, Junio C Hamano wrote:
>> Stefan Beller writes:
>>
>>> ...
>>> fixed.
>>> ...
>>> fixed the text...
>>> ...
>>> I am not fully convinced all descriptions are in recent history,
Dear git Community,
This is my first post to the git mailing list, so I would first like to
express my gratitude to everyone involved in developing one of my
favorite development tools.
I will make my question short and concrete. My day to day job is doing
Linux kernel integration, which also
Eugeniu Rosca writes:
> file-names. Here comes my actual question. Would it be conceptually fine
> to implement some `git patch-id` parameter, which would allow ignoring
> the file-names (or reducing those to their `basename`) before computing
> the patch id? Or would it
"Robert P. J. Day" writes:
> -This manual describes the convention used throughout Git CLI.
> +This manual describes the conventions used throughout Git CLI.
OK.
> Many commands take revisions (most often "commits", but sometimes
> "tree-ish", depending on the context
Kevin Daudt writes:
> Just for completeness, as it is somewhat covered by point 1 already, but
> there are cases where there is no real ambiguity but you are required to
> add '--' to tell git that it should not look for the file in the working
> tree:
>
> $ git show abc123
Marc-Antoine Ruel writes:
> This tells git grep to skip files longer than a specified length,
> which is often the result of generators and not actual source files.
>
> ...
> +-M::
> +--max-line-len::
> + Match the pattern only for line shorter or equal to this length.
>
Lars Schneider writes:
>> Of course it is possible, if you really wanted to. The code knows
>> if it gave the "we launched and waiting for you" notice, so it can
>> maintain not just one (i.e. "how I close the notice?") but another
>> one (i.e. "how I do so upon an
Great work !!!
Thanks
On Fri, Nov 24, 2017 at 1:55 AM, Torsten Bögershausen wrote:
> On Thu, Nov 23, 2017 at 10:01:40PM +0530, Ashish Negi wrote:
>> Thanks for confirming.
>> Is it possible to track this via a bug number ?
>> It will help me to try out the fix when its available.
Thomas Gummerer writes:
> Factor the functions out, so they can be re-used from other places. In
> particular these functions will be re-used in builtin/worktree.c to make
> git worktree add dwim more.
>
> While there add some docs to the function.
>
> Signed-off-by:
Stefan Beller writes:
> Sometimes users are given a hash of an object and they want to
> identify it further (ex.: Use verify-pack to find the largest blobs,
> but what are these? or [1])
>
> One might be tempted to extend git-describe to also work with blobs,
> such that
Phil Hord writes:
> `git stash push -m foo` uses "foo" as the message for the stash. But
> `git stash push -m"foo"` does not parse successfully. Similarly
> `git stash push --message="My stash message"` also fails. The stash
> documentation doesn't suggest this syntax
Thomas Gummerer writes:
> diff --git a/t/t2025-worktree-add.sh b/t/t2025-worktree-add.sh
> index b5c47ac602..53042ce565 100755
> --- a/t/t2025-worktree-add.sh
> +++ b/t/t2025-worktree-add.sh
> @@ -313,5 +313,60 @@ test_expect_success 'checkout a branch under bisect' '
>
"Philip Oakley" writes:
>> We do not know until this change is released to the wild, at which
>> time we will hear noises about the lack of expected ellipses their
>> (poorly written) scripts rely on and tell them to set the workaround
>> environment variable. We may not
Junio C Hamano writes:
> Your suggesting to mention that particular message hints at me that
> you feel that the users may not necessarily understand that push did
> not result in any update of references on the other side when they
> see it. If the message was clear enough
"Robert P. J. Day" writes:
> This command uses a binary search algorithm to find which commit in
> -your project's history introduced a bug. You use it by first telling
> -it a "bad" commit that is known to contain the bug, and a "good"
> -commit that is known to be
Junio C Hamano writes:
>> - * Without disambiguating `--`, Git makes a reasonable guess, but errors
>> - out and asking you to disambiguate when ambiguous. E.g. if you have a
>> - file called HEAD in your work tree, `git diff HEAD` is ambiguous, and
>> + * In cases where
Thomas Gummerer writes:
> Currently 'git worktree add ', errors out when 'branch'
> is not a local branch. It has no additional dwim'ing features that one
> might expect.
>
> Make it behave more like 'git checkout ' when the branch doesn't
> exist locally, but a remote
On Thu, Nov 23, 2017 at 6:45 PM, Max Kirillov wrote:
> [PATCH] http-backend: respect CONTENT_LENGTH as specified by rfc3875
The "RFC" seems to be missing from the subject line of this unpolished patch.
> http-backend reads whole input until EOF. However, the RFC 3875 specifies
On Thu, Nov 23, 2017 at 2:28 PM, Elijah Newren wrote:
> On Thu, Nov 23, 2017 at 3:52 AM, Adam Dinwoodie wrote:
>> On Tuesday 21 November 2017 at 12:00 am -0800, Elijah Newren wrote:
>>>
>>>
>>> merge-recursive.c | 1243 +++-
>>>
Thomas Gummerer writes:
> Currently 'git worktree add ' creates a new branch named after the
> basename of the , that matches the HEAD of whichever worktree we
> were on when calling "git worktree add ".
>
> Make 'git worktree add behave more like the dwim machinery in
>
Welcome to HEARTLAND LOAN FIRM, we give out loans from the range of € 9,000 to
€ 900,000,000
at 2% interest rate.
Kindly apply by providing the details below -
Your name ..
Your country ...
Amount of loan needed .
Phone number ...
REGARDS
CHARLENE TAYLOR
HEARTLAND LOAN FIRM
Hi dear,
My name is Precious, I saw your profile and i became interested in
you, I will also like to know you more, please contact me with this
e-mail address so I can give you my picture for you to know whom I am,
because I have something very important to tell you.
Precious.
On Tuesday 21 November 2017 at 12:00 am -0800, Elijah Newren wrote:
>
>
> merge-recursive.c | 1243 +++-
> merge-recursive.h | 17 +
> t/t3501-revert-cherry-pick.sh |5 +-
> t/t6043-merge-rename-directories.sh | 3821
>
On Wed, Nov 22 2017, Jonathan Nieder jotted:
> Hi,
>
> Ævar Arnfjörð Bjarmason wrote:
>
>> Add LIBPCRE1 and LIBPCRE2 prerequisites which are true when git is
>> compiled with USE_LIBPCRE1=YesPlease or USE_LIBPCRE2=YesPlease,
>> respectively.
>>
>> The syntax of PCRE1 and PCRE2 isn't the same in
On Wed, Nov 22 2017, Eric Sunshine jotted:
> On Wed, Nov 22, 2017 at 8:36 AM, Ævar Arnfjörð Bjarmason
> wrote:
>> Fix a bug in the compilation of PCRE2 patterns under JIT (the most
>> common runtime configuration), any pattern with a (*NO_JIT) verb would
>> segfault. This bug
On Wed, Nov 22, 2017 at 01:36:30PM +, Ævar Arnfjörð Bjarmason wrote:
> + *
> + * This is because if the pattern contains the
> + * (*NO_JIT) verb (see pcre2syntax(3))
> + * pcre2_jit_compile() will exit early with 0. If we
> + *
On 2017-11-23 02:31 (GMT-05:00) anatoly techtonik wrote
>Subject: Re: Unify annotated and non-annotated tags
>On Sat, Nov 11, 2017 at 5:06 AM, Junio C Hamano wrote:
>> Igor Djordjevic writes:
>>
>>> If you would like to mimic output of "git
This tells git grep to skip files longer than a specified length,
which is often the result of generators and not actual source files.
Signed-off-by: Marc-Antoine Ruel
---
Documentation/git-grep.txt | 5 +
builtin/grep.c | 2 ++
grep.c |
On Thu, Nov 23, 2017 at 02:45:44AM -0500, Robert P. J. Day wrote:
> > It's pretty clear to me as it is, but maybe we can write it differently.
> > Like:
> >
> > Without a disambiguating `--`, Git makes a reasonable guess. If it
> > cannot guess (because your request is ambiguous), then it
Hi,
I am working with a team that owns a repository with lots of UTF-16 files.
Converting these files to UTF-8 is no good option as downstream applications
require the UTF-16 encoding. Keeping the files in UTF-16 is no good option
either as Git and Git related tools (e.g. GitHub) consider the
Thanks for confirming.
Is it possible to track this via a bug number ?
It will help me to try out the fix when its available.
On Thu, Nov 16, 2017 at 9:45 PM, Torsten Bögershausen wrote:
> On Thu, Nov 16, 2017 at 12:35:33AM +0530, Ashish Negi wrote:
>> On windows :
>> > git
Good day,
I am Mr. Sam Azada from Burkina Faso a Minister confide on me to look
for foreign partner who will assist him to invest the sum of Fifty
Million Dollars ($50,000,000) in your country.
He has investment interest in mining, exotic properties for commercial
resident, development
Add LIBPCRE1 and LIBPCRE2 prerequisites which are true when git is
compiled with USE_LIBPCRE1=YesPlease or USE_LIBPCRE2=YesPlease,
respectively.
The syntax of PCRE1 and PCRE2 isn't the same in all cases (see
pcresyntax(3) and pcre2syntax(3)). If test are added that test for
those they'll need to
Fix a bug in the compilation of PCRE2 patterns under JIT (the most
common runtime configuration). Any pattern with a (*NO_JIT) verb would
segfault in any currently released PCRE2 version:
$ git grep -P '(*NO_JIT)hi.*there'
Segmentation fault
That this segfaulted was a bug in PCRE2
On Thu, Nov 23, 2017 at 10:41 AM, Marc-Antoine Ruel wrote:
> This tells git grep to skip files longer than a specified length,
s/files/lines/
> which is often the result of generators and not actual source files.
>
> Signed-off-by: Marc-Antoine Ruel
>
On Thu, Nov 23, 2017 at 04:18:59PM +0100, Lars Schneider wrote:
> Hi,
>
> I am working with a team that owns a repository with lots of UTF-16 files.
> Converting these files to UTF-8 is no good option as downstream applications
> require the UTF-16 encoding. Keeping the files in UTF-16 is no good
Hi,
I'm trying to install Git-2.15.0-64-bit.exe onto my Windows 10 machine.
When I run this installer program no matter what options I try or
whether I run as administrator it ends up with an error box saying "The
drive or UNC share you selected does not exist or is not accessible.
Please
On Thu, Nov 23, 2017 at 10:01:40PM +0530, Ashish Negi wrote:
> Thanks for confirming.
> Is it possible to track this via a bug number ?
> It will help me to try out the fix when its available.
>
No worry, the fix is nearly complete and will come out in a couple of days.
On Thu, Nov 23, 2017 at 08:51:55AM -0500, Jeff King wrote:
> On Thu, Nov 23, 2017 at 02:45:44AM -0500, Robert P. J. Day wrote:
>
> > > It's pretty clear to me as it is, but maybe we can write it differently.
> > > Like:
> > >
> > > Without a disambiguating `--`, Git makes a reasonable guess. If
Am 23.11.2017 um 16:08 schrieb Randall S. Becker:
[...]
>> So my proposal is to get rid of non-annotated tags, so to get all
>> tags with commits that they point to, one would use:
>> git for-each-ref --format='%(*objectname) %(refname)' refs/tags>
>> For so-called non-annotated tags just leave
[ +Cc: Git for Windows mailing list ]
Hi Phil,
On 23/11/2017 19:51, Phil Martel wrote:
> I'm trying to install Git-2.15.0-64-bit.exe onto my Windows 10
> machine. When I run this installer program no matter what options I
> try or whether I run as administrator it ends up with an error box
On 23/11/2017 22:30, Mail Delivery Subsystem wrote:
> Hello igor.d.djordje...@gmail.com,
>
> We're writing to let you know that the group you tried to contact
> (git-for-windows) may not exist, or you may not have permission to post
> messages to the group. A few more details on why you weren't
On Thu, Nov 23, 2017 at 3:52 AM, Adam Dinwoodie wrote:
> On Tuesday 21 November 2017 at 12:00 am -0800, Elijah Newren wrote:
>>
>>
>> merge-recursive.c | 1243 +++-
>> merge-recursive.h | 17 +
>> t/t3501-revert-cherry-pick.sh
Thank you. I'll look into it.
Best wishes,
--Phil Martel
On 11/23/2017 4:30 PM, Igor Djordjevic wrote:
[ +Cc: Git for Windows mailing list ]
Hi Phil,
On 23/11/2017 19:51, Phil Martel wrote:
I'm trying to install Git-2.15.0-64-bit.exe onto my Windows 10
machine. When I run this
Hi Buga,
That solved my problem. I apparently had enough cruft left over from a
hard disk issue for Windows to think I still had a copy of Git
installed. when I got rid of it, the new version installed with no
problems.
Thanks again,
--Phil Martel
On 11/23/2017 4:30 PM, Igor Djordjevic
http-backend reads whole input until EOF. However, the RFC 3875 specifies
that a script must read only as many bytes as specified by CONTENT_LENGTH
environment variable. This causes hang under IIS/Windows, for example.
Make http-backend read only CONTENT_LENGTH bytes, if it's defined, rather than
Hi Phil,
On 24/11/2017 00:44, Phil Martel wrote:
> On 11/23/2017 4:30 PM, Igor Djordjevic wrote:
>> On 23/11/2017 19:51, Phil Martel wrote:
>>> I'm trying to install Git-2.15.0-64-bit.exe onto my Windows 10
>>> machine. When I run this installer program no matter what
>>> options I try or
51 matches
Mail list logo