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 break the concept of patc
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 `git describe ` gives a
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 inc
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, but I
>>> tend to agree that most are, so probably the trade
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
> 'git checkout ', i.e. ch
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 tracking branch uniquely
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' '
> test_expect_success 'rena
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: Thomas Gummerer
> ---
> Ma
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 error?") and use it in the err
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.
>>
>
> No worry,
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 a Git command is tru
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 CONTENT_LENGTH byte
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 v1 of this series and 1/2 of v2?
IOW, where
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 should work, but gitcli
>
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 written
> largely
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 +++-
>>> merge-recursive.h |
"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 and command) and paths a
"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 before the bug was introduced
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 to them, "when it rea
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.
> +
All the excellent
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
> that a script mu
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 deleted_file.txt
>
"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 hear from such people at
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 wheth
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 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
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 installer
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 |5 +-
>> t/t
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
[ +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
>
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 t
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
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 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
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
> ---
> diff --git a/Documentation/git-grep.t
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 se
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 proper
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 --version
>> git vers
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 | 4
grep.h
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 file
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 show-ref", repeating
>>> commits for each tag pointing
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 b
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 itself,
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 will
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
>
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
HEA
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 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 dates back to my 94
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 a
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
> + * t
51 matches
Mail list logo