* [git pull] vfs.git regression fix
@ 2016-01-15 20:18 Al Viro
2016-01-15 20:41 ` Linus Torvalds
0 siblings, 1 reply; 7+ messages in thread
From: Al Viro @ 2016-01-15 20:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, linux-fsdevel
Fix for braino introduced in vfs.git#work.misc. Please, pull from
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git
Shortlog:
Borislav Petkov (1):
amdkfd: Copy from the proper user command pointer
Diffstat:
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [git pull] vfs.git regression fix
2016-01-15 20:18 [git pull] vfs.git regression fix Al Viro
@ 2016-01-15 20:41 ` Linus Torvalds
2016-01-15 21:00 ` Al Viro
0 siblings, 1 reply; 7+ messages in thread
From: Linus Torvalds @ 2016-01-15 20:41 UTC (permalink / raw)
To: Al Viro; +Cc: Linux Kernel Mailing List, linux-fsdevel
Al,
_please_ learn to be more careful about your pull requests.
This one is garbage.
Why?
You ask me to pull from the wrong source. You ask me to pull from
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
but that is some random state from January 2014. Two years ago.
What you actually *meant* was apparently the "for-linus" branch, since
that matches the shortlog and diffstat. But that's not what your pull
request asked me to pull.
This is not the first time. You seem to either use buggy scripts, or
do this (wrong) by hand. Please fix whatever it is, so that I don't
have to go look or guess after I notice that I pulled crap.
Linus
On Fri, Jan 15, 2016 at 12:18 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> Fix for braino introduced in vfs.git#work.misc. Please, pull from
> git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git
>
> Shortlog:
> Borislav Petkov (1):
> amdkfd: Copy from the proper user command pointer
>
> Diffstat:
> drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [git pull] vfs.git regression fix
2016-01-15 20:41 ` Linus Torvalds
@ 2016-01-15 21:00 ` Al Viro
2016-01-15 21:08 ` Linus Torvalds
0 siblings, 1 reply; 7+ messages in thread
From: Al Viro @ 2016-01-15 21:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List, linux-fsdevel
On Fri, Jan 15, 2016 at 12:41:06PM -0800, Linus Torvalds wrote:
> Al,
> _please_ learn to be more careful about your pull requests.
>
> This one is garbage.
>
> Why?
>
> You ask me to pull from the wrong source. You ask me to pull from
>
> git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
>
> but that is some random state from January 2014. Two years ago.
>
> What you actually *meant* was apparently the "for-linus" branch, since
> that matches the shortlog and diffstat. But that's not what your pull
> request asked me to pull.
>
> This is not the first time. You seem to either use buggy scripts, or
> do this (wrong) by hand. Please fix whatever it is, so that I don't
> have to go look or guess after I notice that I pulled crap.
Buggy scripts, actually. The thing that generates them takes a branch
name as argument; turns out that it (pretty much by accident) treats the
missing argument as HEAD. Which tends to give reasonable diffstat and
shortlog, so I hadn't spotted the missing check until now.
Fixed. BTW, is there any better way to get the current branch name than
git branch |sed -ne '/\* /s///p'?
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [git pull] vfs.git regression fix
2016-01-15 21:00 ` Al Viro
@ 2016-01-15 21:08 ` Linus Torvalds
2016-01-16 13:44 ` Al Viro
0 siblings, 1 reply; 7+ messages in thread
From: Linus Torvalds @ 2016-01-15 21:08 UTC (permalink / raw)
To: Al Viro; +Cc: Linux Kernel Mailing List, linux-fsdevel
On Fri, Jan 15, 2016 at 1:00 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> Buggy scripts, actually. The thing that generates them takes a branch
> name as argument; turns out that it (pretty much by accident) treats the
> missing argument as HEAD. Which tends to give reasonable diffstat and
> shortlog, so I hadn't spotted the missing check until now.
You could try "git request-pull". It _used_ to have somewhat similar
issues, especially when the local branch had not made it to the remote
point yet, but it should be good now. It actually warns if the remote
name you give doesn't contain what the local branch contanis etc.
> Fixed. BTW, is there any better way to get the current branch name than
> git branch |sed -ne '/\* /s///p'?
"git symbolic-ref HEAD" will show what HEAD points to. That's probably
what you'd want..
Not that there is anything *wrong* with looking at "git branch"
output, but that's really meant to be more human-readable than for
scripting.
Linus
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [git pull] vfs.git regression fix
2016-01-15 21:08 ` Linus Torvalds
@ 2016-01-16 13:44 ` Al Viro
2016-01-16 19:05 ` Linus Torvalds
2016-01-18 7:49 ` Tomi Valkeinen
0 siblings, 2 replies; 7+ messages in thread
From: Al Viro @ 2016-01-16 13:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List, linux-fsdevel
On Fri, Jan 15, 2016 at 01:08:44PM -0800, Linus Torvalds wrote:
> On Fri, Jan 15, 2016 at 1:00 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> >
> > Buggy scripts, actually. The thing that generates them takes a branch
> > name as argument; turns out that it (pretty much by accident) treats the
> > missing argument as HEAD. Which tends to give reasonable diffstat and
> > shortlog, so I hadn't spotted the missing check until now.
>
> You could try "git request-pull". It _used_ to have somewhat similar
> issues, especially when the local branch had not made it to the remote
> point yet, but it should be good now. It actually warns if the remote
> name you give doesn't contain what the local branch contanis etc.
Having checked how git request-pull reacts to missing branch argument...
Very similar bug there - it gives stats for HEAD and URI with no branch
name. Might've been fixed in later versions (it's 2.1.4 here - debian-stable)
FWIW, the main inconvenience with git request-pull is that it still needs
s/gitolite@ra.kernel.org:/git:\/\/git.kernel.org/ postprocessing. It mimics
the git push, but the remote you are pushing to probably won't be usable for
pulling by others. Looks like it would be useful to have something like
pull_url = git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git
to go with
url = gitolite@ra.kernel.org:/pub/scm/linux/kernel/git/viro/vfs.git
in .git/config, settable by something in git remote. OTOH, it's possible to
emulate by setting an extra remote and using git push vfs <...> for pushes,
while doing git request-pull origin vfs-pull <...> for pull requests...
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [git pull] vfs.git regression fix
2016-01-16 13:44 ` Al Viro
@ 2016-01-16 19:05 ` Linus Torvalds
2016-01-18 7:49 ` Tomi Valkeinen
1 sibling, 0 replies; 7+ messages in thread
From: Linus Torvalds @ 2016-01-16 19:05 UTC (permalink / raw)
To: Al Viro; +Cc: Linux Kernel Mailing List, linux-fsdevel
On Sat, Jan 16, 2016 at 5:44 AM, Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> Having checked how git request-pull reacts to missing branch argument...
A missing branch name is the same as HEAD, so:
> Very similar bug there - it gives stats for HEAD and URI with no branch
> name. Might've been fixed in later versions (it's 2.1.4 here - debian-stable)
If you say "no branch name", then it assumes that it's head in your
local and remote repositories.
So it's expected. It also *should* warn about the fact that the remote
repository HEAD does not match. Does it not do that?
Anyway, in general, you should always use a branch-name for "git
request-pull", since you use branches. The "no branch name" is really
only meant for the very original kind of git workflow where you don't
use branches at all. Some people still do that (David Miller seems to
prefer separate repositories over multiple branches, for example), but
it's starting to be unusual.
Also, if your local branch is named differently from your remote one,
you need to use the same format as you would have done for "git push"
to push it out, so you'd do
git request-pull remote-repo local-branch-name:remote-branch-name
but quite frankly, I wouldn't recommend that workflow. I think it's
too prone to mistakes.
> FWIW, the main inconvenience with git request-pull is that it still needs
> s/gitolite@ra.kernel.org:/git:\/\/git.kernel.org/ postprocessing.
So what I always do on all my repositories is that "origin" ends up
being the public thing, and then I have a separate set of things I
push to.
Now, the reason I do that is that pushing is different from pulling,
not only because of the whole security thing, but because I push to
multiple repos.
So my .gti/config looks roughly like this:
[remote "origin"]
url = git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
[remote "all"]
url = ra.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux
url = git@github.com:torvalds/linux.git
and that means that when I pull from my own remote (which I actually
do when I travel - it's hoe I synchronize my laptop and desktop), I
use origin. And when I push, I do "git push all", and it pushes to
both kernel.org and to the github "mirror".
And a plain "git push" simply won't work, which is fine.
Linus
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [git pull] vfs.git regression fix
2016-01-16 13:44 ` Al Viro
2016-01-16 19:05 ` Linus Torvalds
@ 2016-01-18 7:49 ` Tomi Valkeinen
1 sibling, 0 replies; 7+ messages in thread
From: Tomi Valkeinen @ 2016-01-18 7:49 UTC (permalink / raw)
To: Al Viro; +Cc: Linus Torvalds, Linux Kernel Mailing List, linux-fsdevel
[-- Attachment #1: Type: text/plain, Size: 1027 bytes --]
On 16/01/16 15:44, Al Viro wrote:
> FWIW, the main inconvenience with git request-pull is that it still needs
> s/gitolite@ra.kernel.org:/git:\/\/git.kernel.org/ postprocessing. It mimics
> the git push, but the remote you are pushing to probably won't be usable for
> pulling by others. Looks like it would be useful to have something like
> pull_url = git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git
> to go with
> url = gitolite@ra.kernel.org:/pub/scm/linux/kernel/git/viro/vfs.git
> in .git/config, settable by something in git remote. OTOH, it's possible to
> emulate by setting an extra remote and using git push vfs <...> for pushes,
> while doing git request-pull origin vfs-pull <...> for pull requests...
Isn't "pushurl" for that? I have:
[remote "origin"]
url = git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git
pushurl = gitolite.kernel.org:/pub/scm/linux/kernel/git/tomba/linux.git
fetch = +refs/heads/*:refs/remotes/origin/*
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2016-01-18 7:49 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-01-15 20:18 [git pull] vfs.git regression fix Al Viro
2016-01-15 20:41 ` Linus Torvalds
2016-01-15 21:00 ` Al Viro
2016-01-15 21:08 ` Linus Torvalds
2016-01-16 13:44 ` Al Viro
2016-01-16 19:05 ` Linus Torvalds
2016-01-18 7:49 ` Tomi Valkeinen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).