Re: Orangefs, v4.5 and the merge window...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



 > it's in my tree now and I'll push it out after

That is beyond awesome!

I tried to make a signed tag, but never got past:

"You need a passphrase to unlock the secret key..."

it just sat there waiting for me to... do something?
I was ssh'd into my workstation at work, perhaps
the prompt came out there?

I config'd git with my public key as reported
by gpg --list-keys

"git config --global user.signingkey xyzzy"

Anyhow, I'll  work to make sure I can do it
properly next time, thanks so much for
taking Orangefs!

And, please enjoy this cartoon I drew in the spirit it
is offered <g>:

http://myweb.clemson.edu/~hubcap/toons/shipIt.jpg

-Mike


On Sat, Mar 26, 2016 at 3:51 PM, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Sat, Mar 26, 2016 at 12:00 PM, Mike Marshall <hubcap@xxxxxxxxxxxx> wrote:
>>
>> I made the tag right on top of the last thing in our branch that we
>> got from Linus: b562e44f5
>
> So you really don't need to make *that* a tag.
>
> The only tag you want to have is the tag that describes your own
> top-of-tree if you want to send me a signed tag (which really is the
> preferred mode).
>
> Then, all you do is:
>
>  - have some pointer to my tree - it's often just "origin", but you
> can also literally just fetch my tree into a separate branch
>
>    (note the *fetch* - not a pull. So you can do something like
>
>  - give that origin pointer as the start
>
> So something like
>
>     git remote add linus
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>
> would add the remote "linus" (unless you already have a remote
> "origin" that points to that upstream repository), and then you can
> just do
>
>     git fetch linus
>
> and that will get whatever state I have at the time into your
> "linus/master" branch. Note that the "git remote add" you only need to
> do once (and again, a "git clone" will automatically add an "origin"
> remote, so you may have one already).
>
> Then, the best practices is to make a signed tag of *your* work - you
> could call it something like "for-linus-4.6", for example:
>
>     git tag -s for-linus-4.6
>
> and write a tag message and sign it with your key. I prefer that
> signed tag to contain some useful description of what I'm actually
> pulling, not just "Orangefs: pull-tag-1". And I do really want it to
> be a *signed* tag for it to actually make sense.
>
> After that, just do
>
>     git request-pull remotes/linus/master \
>         git://git.kernel.org/pub/scm/linux/kernel/git/hubcap/linux.git
> tags/for-linus-4.6
>
> which should do the right thing.
>
> That said, the request-pull you sent out looks mostly fine - it's just
> that you did an unnecessary tag there to create the base commit that
> you really shouldn't have needed to do, and the tag you asked me to
> pull was an unsigned one and didn't contain any useful information.
>
> So I pulled it, but for next time:
>
>  - please use a signed tag. I don't actually require it for kernel.org
> pulls, but it's nice, and it's particularly nice if the signed tag
> contents then describe what I'm pulling
>
>  - don't do the extraneous tag that doesn't actually help or matter.
>
> but it's in my tree now and I'll push it out after
>
>             Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux