lkml.org 
[lkml]   [2012]   [Mar]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [GIT PULL] Please pull NFS client bugfixes for Linux 3.4...
On Wed, Mar 28, 2012 at 9:38 PM, Myklebust, Trond
<Trond.Myklebust@netapp.com> wrote:
>
> When I do the tags/nfs-for-3.4-1, it still gives me that ..BRANCH.NOT.VERIFIED.. crap in the pull message.

Hmm. Maybe it does end up only working for a branch in the pre-1.7.9
days. I haven't tested - I don't use old git versions.

> Furthermore, it fails to actually push the tag to my upstream repository, meaning that I'm still prone to the 'Linus tried to pull, and the commit wasn't there" syndrome.

Well, that's a separate issue. Yes, you obviously need to push first.

I would not object to you scripting the "push before pull request". I
just object to people using a script that is *worse* than what git
actually contains natively to actually generate the pull request.

> Could we perhaps set up a best practices webpage/wiki for this sort of thing with a pointer to that webpage in Documentations/SubmittingPatches? That way maintainers would have a source of information for which versions of 'git' that they need to use in order to provide you with the information that you want.

The nice signed tag understanding came in 1.7.9. But I actually
seriously suggest that all kernel developers use something even more
recent than that, since what changes in 1.7.10 (not released yet, but
the git 'master' branch is at rc3 now) is the extremely nice "make
people actually explain their merges" change.

There have been kernel developers that apparently never even noticed
that they were creating extraneous merges, so I really encourage
everybody to upgrade to current pre-1.7.10 git just so that you are
asked to write a nice merge message when you create a merge. That's
totally independent of the signed tag issue and the nice pull-request
format, though.

And it really is *trivial* to use a modern git instead of whatever
distro version you have. It's literally:

git clone git://github.com/gitster/git
cd git
make
make install

all as a *regular*user* (do not 'sudo make install'!). That installs
git in your own ~/bin directory, there's no fighting with whatever
distro git versions. No need to uninstall things or worry about
/usr/local or anything like that.

The git master branch is extremely stable, it's not very scary at all
to be up-to-date. And it's almost always better than whatever distro
version you have, and as seen above it really isn't hard to do. You
may need to install a few libraries, but git doesn't really even have
very complex dependencies. The two that might bite some people is the
need for the curl-devel and expat-devel packages.

(If you don't have any development environment at *all*, you need to
install gcc, make, zlib-devel, openssl-devel, and gettext, but those
tend to be in the development base, so you almost certainly already
have them)

Obviously you then need to have something like

PATH="$(HOME)/bin:$PATH"

in your .bashrc to make sure that your own private binaries override
the system ones, but hey, that's just a good idea regardless if you
are a developer and ever want to use your own programs.

Linus


\
 
 \ /
  Last update: 2012-03-29 07:01    [W:0.045 / U:1.828 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site