linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [git pull] vfs.git regression fix
Date: Sat, 16 Jan 2016 11:05:54 -0800	[thread overview]
Message-ID: <CA+55aFx-EQ4gyiNBZbvHootZKtxsumdDaRD2eHAazYaBBpbG9g@mail.gmail.com> (raw)
In-Reply-To: <20160116134458.GK17997@ZenIV.linux.org.uk>

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

  reply	other threads:[~2016-01-16 19:05 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2016-01-18  7:49         ` Tomi Valkeinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CA+55aFx-EQ4gyiNBZbvHootZKtxsumdDaRD2eHAazYaBBpbG9g@mail.gmail.com \
    --to=torvalds@linux-foundation.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).