[jc: some people CC'ed because I'll talk about logallrefupdates
at the end]
Pavel Roskin <proski@xxxxxxx> 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").
> 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"?
If so, the line does _not_ say that. It does not talk about
pulling nor merging. What it says is "My refs/heads/pu is used
as a tracking branch for keeping track of the progress of his
'pu'; because I know he rewinds and rebases, please override the
fast-forward check when you store the updated value of his 'pu'
to my 'refs/heads/pu'".
> 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?
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.
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.
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?
diff --git a/refs.c b/refs.c
index 8b2a3c1..e88ed8b 100644
--- a/refs.c
+++ b/refs.c
@@ -925,7 +925,8 @@ static int log_ref_write(struct ref_lock *lock,
const char *committer;
if (log_all_ref_updates &&
- !strncmp(lock->ref_name, "refs/heads/", 11)) {
+ (!strncmp(lock->ref_name, "refs/heads/", 11) ||
+ !strncmp(lock->ref_name, "refs/remotes/", 13))) {
if (safe_create_leading_directories(lock->log_file) < 0)
return error("unable to create directory for %s",
lock->log_file);
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html