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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+55aFxc3mWO7n2kxqqVDPhpSF8k92gxk+-GCh8_cUVoo0LP_A@mail.gmail.com>
Date:	Thu, 26 May 2016 19:05:11 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Dave Chinner <david@...morbit.com>
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 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

It was a misguided attempt at automatically just "doing the right
thing" and being easier to use, but yes, it means that it does
something subtly different from what you ask for if you haven't pushed
out the remote you talked about yet.

Bu that was all fixed about two years ago, and I think made v2.0.

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?

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).

               Linus