On Mon, 2 Jun 2014 19:59:53 -0700 Linus Torvalds
wrote:
> On Mon, Jun 2, 2014 at 7:08 PM, NeilBrown wrote:
> >
> > git request-pull master git://neil.brown.name/md
> >
> > after tagging the current commit as "md/3.15-fixes" and pushing out the tag
>
> You should *tell* "git request-pull" what
On Mon, Jun 2, 2014 at 7:08 PM, NeilBrown wrote:
>
> git request-pull master git://neil.brown.name/md
>
> after tagging the current commit as "md/3.15-fixes" and pushing out the tag
You should *tell* "git request-pull" what you're actually requesting to pull.
The old "let's guess based on the
On Wed, 28 May 2014 15:31:13 -0700 Junio C Hamano wrote:
> The latest feature release Git v2.0.0 is now available at the
> usual places.
>
> "git request-pull" lost a few "heuristics" that often led to mistakes.
>
I've installed git 2.0.0 and now when I
git request-pull master git://neil.
Jeff King writes:
> On Sat, May 31, 2014 at 11:52:24AM +0200, David Kastrup wrote:
>
>> Some mailing list filters and/or spam filters flag mails with too many
>> recipients so that they need to pass through moderation first. The
>> typical threads on this list are short and have few recipients w
Jeff King wrote:
> On Sat, May 31, 2014 at 11:52:24AM +0200, David Kastrup wrote:
> > And frankly, if I were a list moderator and software asked me through
> > this sort of coincidence whether a mail should be delivered or not and a
> > glance at it shows nothing but insults, wild accusations, thr
On Sat, May 31, 2014 at 11:52:24AM +0200, David Kastrup wrote:
> Some mailing list filters and/or spam filters flag mails with too many
> recipients so that they need to pass through moderation first. The
> typical threads on this list are short and have few recipients while
> longer threads, due
Felipe Contreras writes:
> Jeff King wrote:
>> On Wed, May 28, 2014 at 06:17:25PM -0500, Felipe Contreras wrote:
>>
>> > This is the last mail I sent to you, because you ignore them anyway, and
>> > remove them from the mailing list.
>> > [...]
>> > [2], a mail you conveniently removed from the
Jeff King wrote:
> On Wed, May 28, 2014 at 06:17:25PM -0500, Felipe Contreras wrote:
>
> > This is the last mail I sent to you, because you ignore them anyway, and
> > remove them from the mailing list.
> > [...]
> > [2], a mail you conveniently removed from the tracked record.
> > [...]
> > You a
On Thu, May 29, 2014 at 09:23:06PM +0200, David Kastrup wrote:
> > I do not think Junio or anyone else has the technical ability to remove
> > messages from the archive.
>
> You can post self-destructing messages by adding X-no-archive: yes if I
> am not mistaken. But that only concerns stuff yo
Jeff King writes:
> On Wed, May 28, 2014 at 06:17:25PM -0500, Felipe Contreras wrote:
>
>> This is the last mail I sent to you, because you ignore them anyway, and
>> remove them from the mailing list.
>> [...]
>> [2], a mail you conveniently removed from the tracked record.
>> [...]
>> You also
On Wed, May 28, 2014 at 06:17:25PM -0500, Felipe Contreras wrote:
> This is the last mail I sent to you, because you ignore them anyway, and
> remove them from the mailing list.
> [...]
> [2], a mail you conveniently removed from the tracked record.
> [...]
> You also conveniently removed this mai
Felipe Contreras wrote:
> In mail [3] you acknowledged my wish, and you said you were going to put
> stubs for v2.0, and you didn't. You also conveniently removed this mail
> from the archives.
My bad. You actually did it. I missed it because the commit is named
'Revert "Merge branch 'jc/graduate-
This is the last mail I sent to you, because you ignore them anyway, and
remove them from the mailing list.
I'm am cc'ing the git-fc mailing list so there's a public track record
of this, so you can't claim it didn't happen.
Junio C Hamano wrote:
> * The "remote-hg/bzr" remote-helper interfaces
Junio C Hamano writes:
> The tarballs are found at:
>
> https://www.kernel.org/pub/software/scm/git/testing/
Heh, I do not know how this slipped in, but the real release tarball
is not in git/testing/ but found at:
https://www.kernel.org/pub/software/scm/git/
--
To unsubscribe from th
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > Junio C Hamano wrote:
> >
> >> * The remote-helper interface to fast-import/fast-export via the
> >>transport-helper has been tightened to avoid leaving the import
> >>marks file from a failed/crashed run, as such a file that is out-
Richard Hansen writes:
>> * The shell prompt script (in contrib/), when using the PROMPT_COMMAND
>>interface, used an unsafe construct when showing the branch name in
>>$PS1.
>>(merge 8976500 rh/prompt-pcmode-avoid-eval-on-refname later to maint).
>
> That commit has been merged to m
On 2014-05-20 20:24, Junio C Hamano wrote:
> Fixes since v1.9 series
> ---
>
> Unless otherwise noted, all the fixes since v1.9 in the maintenance
> track are contained in this release (see the maintenance releases'
> notes for details).
[...]
>
> * The shell prompt script (in
Felipe Contreras writes:
> Junio C Hamano wrote:
>
>> * The remote-helper interface to fast-import/fast-export via the
>>transport-helper has been tightened to avoid leaving the import
>>marks file from a failed/crashed run, as such a file that is out-of-
>>sync with reality confuses
Martin Erik Werner writes:
>> * Commands that take pathspecs on the command line misbehaved when
>>the pathspec is given as an absolute pathname (which is a
>>practice not particularly encouraged) that points at a symbolic
>>link in the working tree.
>>(merge later 655ee9e mw/sym
On Tue, May 20, 2014 at 05:24:50PM -0700, Junio C Hamano wrote:
(...)
> * "git reset" learned the "-N" option, which does not reset the index
>fully for paths the index knows about but the tree-ish the command
>resets to does not (these paths are kept as intend-to-add entries).
I find it
Felipe Contreras writes:
> Junio C Hamano wrote:
>
>> * The remote-helper interface to fast-import/fast-export via the
>>transport-helper has been tightened to avoid leaving the import
>>marks file from a failed/crashed run, as such a file that is out-of-
>>sync with reality confuses
Junio C Hamano wrote:
> * The remote-helper interface to fast-import/fast-export via the
>transport-helper has been tightened to avoid leaving the import
>marks file from a failed/crashed run, as such a file that is out-of-
>sync with reality confuses a later invocation of itself.
Re
Johan Herland writes:
> I.e. use Kyle's patch to t9117, plus something like this:
>
> diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
> index 5b3c38d..9f579e0 100644
> --- a/Documentation/git-svn.txt
> +++ b/Documentation/git-svn.txt
> @@ -91,6 +91,9 @@ COMMANDS
> NOTE: Before
On Wed, Apr 23, 2014 at 12:47 AM, Junio C Hamano wrote:
> "brian m. carlson" writes:
>> What we could do instead is simply require a newer version of
>> Getopt::Long, which would let people continue using their ancient OSes
>> and install a newer version from CPAN if necessary. It's also the
>>
"brian m. carlson" writes:
> On Tue, Apr 22, 2014 at 03:11:48PM -0700, Jonathan Nieder wrote:
>> Another possibility would be to require Perl 5.8.9 or newer. It was
>> released in 2008.
>
> RHEL 5 and CentOS 5 are still shipping with 5.8.8. They are still
> security-supported until 2017, and be
On Tue, Apr 22, 2014 at 03:11:48PM -0700, Jonathan Nieder wrote:
> Another possibility would be to require Perl 5.8.9 or newer. It was
> released in 2008.
RHEL 5 and CentOS 5 are still shipping with 5.8.8. They are still
security-supported until 2017, and believe it or not people still
develop o
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> The documentation says
>>
>> --prefix=
>>
>> ...
>>
>> Before Git 2.0, the default prefix was "" (no prefix).
>> This meant that ...
>>
>> which suggests that I can use --prefix="" to mean no prefix. P
Jonathan Nieder writes:
> Junio C Hamano wrote:
>> Jonathan Nieder writes:
>
>>> Hm, perhaps we should introduce a 'no-prefix' option to work around
>>> this.
> [...]
>>> That way, normal usage of --prefix would still be consistent with
>>> other git commands that prefer the form with argument a
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> Hm, perhaps we should introduce a 'no-prefix' option to work around
>> this.
[...]
>> That way, normal usage of --prefix would still be consistent with
>> other git commands that prefer the form with argument attached
>> (--prefix=foo, not --pref
Jonathan Nieder writes:
> Hm, perhaps we should introduce a 'no-prefix' option to work around
> this.
> ...
>> |diff --git a/git-svn.perl b/git-svn.perl
>> |index 7349ffea..284f458a 100755
>> |--- a/git-svn.perl
>> |+++ b/git-svn.perl
>> |@@ -149,7 +149,7 @@ my ($_trunk, @_tags, @_branches, $_std
"Kyle J. McKay" writes:
> Alternatively this change can be made in git-svn.perl:
> |diff --git a/git-svn.perl b/git-svn.perl
> |index 7349ffea..284f458a 100755
> |--- a/git-svn.perl
> |+++ b/git-svn.perl
> |@@ -149,7 +149,7 @@ my ($_trunk, @_tags, @_branches, $_stdlayout);
> my %icv;
> my %in
Kyle J. McKay wrote:
> The problem with --prefix="" is this (from the Getopt::Long CHANGES file):
>
> Changes in version 2.37
> ---
>
> * Bugfix: With gnu_compat, --foo= will no longer trigger "Option
>requires an argument" but return the empty string.
>
> The system I ran
On Apr 18, 2014, at 12:37, Junio C Hamano wrote:
> An early preview release Git v2.0.0-rc0 is now available for
> testing at the usual places.
I have run into the following test failures with v2.0.0-rc0:
Test Summary Report
---
t9117-git-svn-init-clone.sh (Wstat: 256
Felipe Contreras writes:
> Junio C Hamano wrote:
>> * transport-helper, fast-import and fast-export have been updated to
>>allow the ref mapping and ref deletion in a way similar to the
>>natively supported transports.
>
> Have they?
Yikes, no. This was me mischaracterizingg the merge
Junio C Hamano wrote:
> * transport-helper, fast-import and fast-export have been updated to
>allow the ref mapping and ref deletion in a way similar to the
>natively supported transports.
Have they?
% git --version
git version 2.0.0.rc0
% git push origin origin master:foo
Johan Herland writes:
> On Fri, Apr 18, 2014 at 9:37 PM, Junio C Hamano wrote:
>> An early preview release Git v2.0.0-rc0 is now available for
>> testing at the usual places.
>
> This is supposed to have _all_ the v2.0 topics, correct?
>
> I'm unable to find the commit that actually _changes_ th
On Fri, Apr 18, 2014 at 9:37 PM, Junio C Hamano wrote:
> An early preview release Git v2.0.0-rc0 is now available for
> testing at the usual places.
This is supposed to have _all_ the v2.0 topics, correct?
I'm unable to find the commit that actually _changes_ the default
prefix for "git svn" (as
37 matches
Mail list logo
