Re: branch.pu.forcefetch
- From
- Pavel Roskin <proski@gnu.org>
- Date
- Dec 29, 2006, 01:22 UTC
- Message-ID
- <1167355326.15189.34.camel@dv>
- In-Reply-To
- <7vzm97tzbt.fsf@assigned-by-dhcp.cox.net>
On Thu, 2006-12-28 at 14:44 -0800, Junio C Hamano wrote:
> [jc: some people CC'ed because I'll talk about logallrefupdates > at the end]
OK.
Show 16 quoted lines
> Pavel Roskin <proski@gnu.org> writes: > > > Actually, it's strange that I don't actually have refs/heads/pu > > under .git, and it doesn't get created even if I run "git-pull" or > > "git-pull origin pu". > > "git-pull" without argument (and "git-pull origin") are affected > by the config (and .git/remotes/origin), so we will look at your > config later. > > With "git-pull origin pu", you are saying "use URL for origin > but this time I am not interested in the set of branches to > fetch by default specified in my config". And single token "pu" > means you do not want to store the fetch result in any tracking > branch (otherwise you would explicitly say "pu:refs/heads/pu" or > "pu:/refs/remotes/origin/pu").
OK, I'm going to take a "bird's view" of it. If you happen to think I'm saying stupid things, it's just because I'm playing an even less experienced user than I am.
I don't think it's a good idea to expose the layout under .git to the end user. I do realize that git is just "plumbing", but things like "refs/heads/" should probably be hidden from the user in any case. Using path as an indicator that something should be saved looks like a kludge.
Maybe we could have a notation for branches on remotes (e.g. pu@origin or origin#pu), tracking branches and non-tracking branches? I would be happy if the same name could be used for all of them. After all, that's the way CVS and Subversion do it, and it's fine for most users. As for the locations under refs, let's leave it to git.
> > We have a line that says: "pull from pu branch of origin and merge it > > into local pu branch even if fast-forward is impossible". > > Are you talking about "remote.origin.fetch = +pu:refs/heads/pu"?
Yes, I'm talking about that line. And I don't like that I have to use a magic token "refs/heads/pu" that doesn't correspond to a real file to make it possible to keep git up-to-date.
[skip]
Show 26 quoted lines
> > However, > > there it no local pu branch. Yet not having this line blocks updating > > of master branch. > > Now that is worrisome. "git pull" and "git pull origin" (but > not "git pull pu" for the reason I mentioned earlier) should > create your "pu" branch if you have the configuration. > > Let me understand the situation. Your config file is: > > > My .git/config file is: > > > > [core] > > repositoryformatversion = 0 > > filemode = true > > logallrefupdates = true > > [remote "origin"] > > url = git://www.kernel.org/pub/scm/git/git.git > > fetch = refs/heads/*:refs/remotes/origin/* > > [branch "master"] > > remote = origin > > merge = refs/heads/master > > So you may not have refs/heads/pu (iow, you do not build on top > of my 'pu'), but the config says refs/remotes/origin/ is used to > track all my branches. Do you have refs/remotes/origin/pu?
Yes. I'm doing a clean checkout now with the current git from the "master" branch:
[proski@dv git]$ git-clone git://www.kernel.org/pub/scm/git/git.git Initialized empty Git repository in /home/proski/tmp/git/git/.git/ remote: Generating pack... remote: Done counting 35273 objects. remote: Deltifying 35273 objects. remote: 100% (35273/35273) done Indexing 35273 objects. remote: Total 35273, written 35273 (delta 24484), reused 35217 (delta 24444) 100% (35273/35273) done Resolving 24484 deltas. 100% (24484/24484) done Checking files out... 100% (761/761) done [proski@dv git]$ git --version git version 1.5.0.rc0.g4a4d [proski@dv git]$ ls git/.git/refs/remotes/origin/ HEAD html maint man master next pu todo [proski@dv git]$ ls git/.git/refs/heads/ master [proski@dv git]$ cd git/ [proski@dv git]$ git-pull Already up-to-date. [proski@dv git]$ ls .git/refs/heads/ master [proski@dv git]$
Show 17 quoted lines
> If so, then "git fetch" would error out exactly because 'pu' > would not fast forward and the config says it does not allow > non-fast-forward fetch. > > It might make sense to make the default configuration git > clone creates to say > > [remote "origin"] > url = git://www.kernel.org/pub/scm/git/git.git > fetch = +refs/heads/*:refs/remotes/origin/* > > instead. > > I think I suggested this once but vaguely recall some people > objected, for the reason that an unusual situation such as > non-fast-forward should always error out for safety and should > require an explicit override by the user.
In this particular case of the GIT project, it's very rare that I would be interested in the "pu" branch. I'm mostly interested in "master", and I can be occasionally interested in "next".
The default for git-clone is to clone all branches. It's OK for me because I'm on a fast connection (I hear angry voices of modem users). Actually, I don't see an option to git-clone to clone HEAD or selected branches only. The "-o" option seems to be something different, even though the manual mention branches.
Unfortunately, updating the current branch fails because pu is not fast-forwarding. Why fail if I'm not even on pu?
In other words, the basic default functionality is hampered because of a branch the user is not even using in any way. And the fix involves editing the config file.
Show 10 quoted lines
> But come to think of it, I think failing to update the remote > tracking branch for non-fast-forward does not buy us very much. > Letting the user to be aware of the situation has value, but at > that point, I do not think there is much else the user can do. > The purpose of the tracking branches is to track what happens on > the remote side, and the user is in no position to override what > has already happend on the remote side (otherwise it stops being > "tracking branches"). If reflogs are enabled on remote tracking > braches, you can always get back the older state if you wanted > to.
I tend to agree. Of course, if any porcelains require or prefer fast-forward, they should be able to prevent non-fast-forward updates. Perhaps they would be OK with non-fast-forward updates on branches other than those they are specifically managing?
> That makes me notice another thing. We do not seem to create > reflog for remotes/ hierarchy even when logallrefupdates is set > to true. Would people object if we did this?
No objection on my part.
-- Regards, Pavel Roskin