linux-kernel - Re: [GIT PULL] xfs: updates for 4.7-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20160530052306.GN26977@dastard>
Date:	Mon, 30 May 2016 15:23:06 +1000
From:	Dave Chinner <david@...morbit.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] xfs: updates for 4.7-rc1

On Thu, May 26, 2016 at 07:05:11PM -0700, Linus Torvalds wrote:
> On Thu, May 26, 2016 at 5:13 PM, Dave Chinner <david@...morbit.com> wrote:
> > On Thu, May 26, 2016 at 10:19:13AM -0700, Linus Torvalds wrote:
> >>
> >> i'm ok with the late branches, it's not like xfs has been a problem spot.
> >
> > Still, I'll try to avoid them because it reduces testing time.
> 
> Oh, 100% agreed. I'm just saying that you get a pass because you've
> historically been very reliable.
> 
> >> Your pull request mentions the 'for-next' branch, but I think you
> >> *meant* to send me the "xfs-for-linus-4.7-rc1" tag which points to the
> >> same commit and has your summary in it.
> >
> > <sigh>
> >
> > Mea culpa. I ran this command after creating the tag:
> >
> > $ git request-pull v4.6 git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs.git tags/xfs-for-linus-4.7-rc1 > ~/tmp/t.txt
> >
> > And I didn't check the output closely enough. I forgot to push the
> > tag to the upstream repo before running request-pull.
> >
> > Git often makes it very easy to make mistakes whilst simultaneously
> > making it hard to notice you've made a mistake. :(
> 
> Actually, that one got fixed in git quite some time ago.
> 
> You probably have a fairly old version of git, which had the "helpful"
> logic to pick another remote location if it couldn't find the exact
> one you had specified, but it could find another one that matched in
> content

Ah, unlike my workstation which is running 2.8.3, the server I host
my all my internal network services (including staging trees) is
running....

> Do you perhaps happen to run something like debian-stable or similar
> that never upgrades major versions, so you're still at git-1.x?

... debian stable.

Given the only thing I do manually in those staging trees is tag
commits, push branches to kernel.org, and run "git request-pull" I
hadn't noticed that I was still on an old git.

> Building your own git is trivial, and a "make install" will just
> install in your ~/bin directory so you don't even have to
> uninstall the system one (assuming you have your own ~/bin before
> /usr/bin in the path, of course).

*nod*

But it's far easier just to do 'apt-get install git/testing'
and have 2.8.1 installed 15s later.... :P

Cheers,

Dave.
-- 
Dave Chinner
david@...morbit.com