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  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]
Date:	Thu, 26 May 2016 19:05:11 -0700
From:	Linus Torvalds <>
To:	Dave Chinner <>
Cc:	Andrew Morton <>,
	Linux Kernel Mailing List <>
Subject: Re: [GIT PULL] xfs: updates for 4.7-rc1

On Thu, May 26, 2016 at 5:13 PM, Dave Chinner <> 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:// 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

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


Powered by blists - more mailing lists