branch.pu.forcefetch

branch.pu.forcefetch

[Pavel Roskin]

Hello!

I'm testing the current git from the master branch, and I like the idea
of moving the remotes to the config file, but I think there is a
significant omission in the new syntax.  There is no way to specify that
some branches are fast forward.

For example, I clone the git repository anew, and I try to update it by
git-fetch a few days later.  I get an error:

* refs/remotes/origin/pu: not updating to non-fast forward branch 'pu'
of git://www.kernel.org/pub/scm/git/git

It would be great to have a "non-fastforward" option in the config file
for every branch.  I'm thinking about something like:

[branch "pu"]
        forcefetch = 1

It would be even better to initialize such option while cloning.

-- 
Regards,
Pavel Roskin

Re: branch.pu.forcefetch

[Jakub Narebski]

Pavel Roskin wrote:

> I'm testing the current git from the master branch, and I like the idea
> of moving the remotes to the config file, but I think there is a
> significant omission in the new syntax.  There is no way to specify that
> some branches are fast forward.
> 
> For example, I clone the git repository anew, and I try to update it by
> git-fetch a few days later.  I get an error:
> 
> * refs/remotes/origin/pu: not updating to non-fast forward branch 'pu'
> of git://www.kernel.org/pub/scm/git/git
> 
> It would be great to have a "non-fastforward" option in the config file
> for every branch. I'm thinking about something like: 
> 
> [branch "pu"]
>         forcefetch = 1

Currently the old '+' before refspec still works. So you should have
[remote "origin"]
        # ...
        fetch = +refs/heads/pu:refs/remotes/origin/pu

> It would be even better to initialize such option while cloning.

There was some talk about this, but I don't remember if there were any code.

Actually the talk was about marking branch as non-fast-forwardable (which
is meant to have rewritten history) on _server_ side, and allowing to
fetch all/parts of config while cloning to get this info.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: branch.pu.forcefetch

[Junio C Hamano]

Pavel Roskin <proski@gnu.org> writes:

> For example, I clone the git repository anew, and I try to update it by
> git-fetch a few days later.  I get an error:
>
> * refs/remotes/origin/pu: not updating to non-fast forward branch 'pu'
> of git://www.kernel.org/pub/scm/git/git

Perhaps you would want something like this?

if you are using separate remote layout:

[remote "origin"]
	fetch = +refs/heads/pu:refs/remotes/origin/pu
	fetch = refs/heads/*:refs/remotes/origin/*

Or traditional layout:

[remote "origin"]
	fetch = refs/heads/master:refs/heads/origin
	fetch = refs/heads/next:refs/heads/next
	fetch = refs/heads/maint:refs/heads/maint
	fetch = +refs/heads/pu:refs/remotes/pu

Re: branch.pu.forcefetch

[Jakub Narebski]

Junio C Hamano wrote:

> Pavel Roskin <proski@gnu.org> writes:
> 
>> For example, I clone the git repository anew, and I try to update it by
>> git-fetch a few days later.  I get an error:
>>
>> * refs/remotes/origin/pu: not updating to non-fast forward branch 'pu'
>> of git://www.kernel.org/pub/scm/git/git
> 
> Perhaps you would want something like this?
> 
> if you are using separate remote layout:
> 
> [remote "origin"]
>       fetch = +refs/heads/pu:refs/remotes/origin/pu
>       fetch = refs/heads/*:refs/remotes/origin/*

By the way, does the ordering matter here, i.e. does it matter if 'pu' fetch
line is before or after wildcards line?

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: branch.pu.forcefetch

[Pavel Roskin]

Hello!

On Wed, 2006-12-27 at 13:14 -0800, Junio C Hamano wrote:
> Pavel Roskin <proski@gnu.org> writes:
> 
> > For example, I clone the git repository anew, and I try to update it by
> > git-fetch a few days later.  I get an error:
> >
> > * refs/remotes/origin/pu: not updating to non-fast forward branch 'pu'
> > of git://www.kernel.org/pub/scm/git/git
> 
> Perhaps you would want something like this?
> 
> if you are using separate remote layout:
> 
> [remote "origin"]
> 	fetch = +refs/heads/pu:refs/remotes/origin/pu
> 	fetch = refs/heads/*:refs/remotes/origin/*

That works.

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".

I realize that I'm far behind in my understanding of GIT, but it seems
to me that something is wrong in the new layout.

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".  However,
there it no local pu branch.  Yet not having this line blocks updating
of master branch.

It's like saying: I won't update master branch because there is another
branch that you are not tracking locally, but if you were, it would not
fast forward.  Seems quite perverse to me.

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

-- 
Regards,
Pavel Roskin

Re: branch.pu.forcefetch

[Junio C Hamano]

[jc: some people CC'ed because I'll talk about logallrefupdates
 at the end]

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").

> 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);

[PATCH 1/2] core.logallrefupdates: log remotes/ tracking branches.

[Junio C Hamano]

Not using reflog for tags/ was very sensible; not giving reflog
for the remotes/ was not.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---
 refs.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

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);
-- 
1.5.0.rc0.gf5c587

[PATCH 2/2] Allow non-fast-forward of remote tracking branches in default clone

[Junio C Hamano]

This changes the default remote.origin.fetch configuration
created by git-clone so that it allows non-fast-forward updates.

When using the separate-remote layout with reflog enabled, it
does not make much sense to refuse to update the remote tracking
branch just because some of them do not fast-forward.  git-fetch
issues warnings on non-fast-forwardness, and the user can peek
at what the previous state was using the reflog.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---
 git-clone.sh |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/git-clone.sh b/git-clone.sh
index f37eb9d..3d388de 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -388,7 +388,7 @@ then
 
 		# Set up the mappings to track the remote branches.
 		git-repo-config remote."$origin".fetch \
-			"refs/heads/*:$remote_top/*" '^$' &&
+			"+refs/heads/*:$remote_top/*" '^$' &&
 		rm -f "refs/remotes/$origin/HEAD"
 		git-symbolic-ref "refs/remotes/$origin/HEAD" \
 			"refs/remotes/$origin/$head_points_at" &&
-- 
1.5.0.rc0.gf5c587

Re: branch.pu.forcefetch

[Pavel Roskin]

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.

> 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]

> > 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]$

> 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.

> 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

Re: branch.pu.forcefetch

[Junio C Hamano]

Pavel Roskin <proski@gnu.org> writes:

>> 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.

I think we misunderstood each other.  That line is inconsistent
with what your config has, which is the separate-remote layout,
which I did not know you were using.  In separate-remote layout,
you don't have refs/heads/pu so if we do not do the patches you
are agreeing to, you would want to have something like:

	[remote "origin"]
                fetch = +refs/heads/pu:refs/remotes/origin/pu
        	fetch = refs/heads/*:refs/remotes/origin/*

In other words, "path does not correspond to a real file"
problem does not exist.  If you tell git to track 'pu' at
refs/remotes/origin/pu, it will use that path -- so that path
has a corresponding real file.

> Unfortunately, updating the current branch fails because pu is not
> fast-forwarding.  Why fail if I'm not even on pu?

Your being not on 'pu' does not have anything to do with it.  In
fact, you do not even want to be _on_ any of your tracking
branches.  In the separate-remote layout, you cannot even be on
remotes/origin/pu branch.

What you are seeing is fetch's safety feature that stops and
notifies you the situation when the remote rewinds/rebases the
branch you are tracking with tracking branches.  We have had it
turned on by default for a long time, and you have it turned on
in your config because that is the default.  If you do not want
to use that feature (and for git.git, you certainly don't), just
turn it off.  When you know you do not want to use a feature,
you do not have to.

Turning it off by default was not a wise thing to do in general
for a long time, because rewound/rebased tip loses information,
and we did not have reflog enabled by default.  Your message
raised this issue to attention of the list, and I suggested two
patches out of it, both of which I think are sane things to do.
If the list agrees, we can turn it off by default now.

Re: branch.pu.forcefetch

[Pavel Roskin]

On Thu, 2006-12-28 at 18:30 -0800, Junio C Hamano wrote:
> Pavel Roskin <proski@gnu.org> writes:
> 
> >> 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.
> 
> I think we misunderstood each other.

I just didn't notice that your question used a different line.  I was
talking about

	fetch = +refs/heads/pu:refs/remotes/origin/pu

> That line is inconsistent
> with what your config has, which is the separate-remote layout,
> which I did not know you were using.  In separate-remote layout,
> you don't have refs/heads/pu so if we do not do the patches you
> are agreeing to, you would want to have something like:
> 
> 	[remote "origin"]
>                 fetch = +refs/heads/pu:refs/remotes/origin/pu
>         	fetch = refs/heads/*:refs/remotes/origin/*

I get it now.  "refs/heads/pu" must be the path on the remote side.

The whole thing remains pretty hairy for my taste, but it looks like we
are going to untangle it step-by-step.

> Turning it off by default was not a wise thing to do in general
> for a long time, because rewound/rebased tip loses information,
> and we did not have reflog enabled by default.  Your message
> raised this issue to attention of the list, and I suggested two
> patches out of it, both of which I think are sane things to do.
> If the list agrees, we can turn it off by default now.

Just a random idea - if fast-forward fails, save the original head
somewhere under refs as a backup.  It's like "patch" saving *.orig files
if there is any doubt that the patch was applied cleanly.

But I'm fine with reflog too.

-- 
Regards,
Pavel Roskin

Re: branch.pu.forcefetch

[Shawn Pearce]

Pavel Roskin <proski@gnu.org> wrote:
> Just a random idea - if fast-forward fails, save the original head
> somewhere under refs as a backup.  It's like "patch" saving *.orig files
> if there is any doubt that the patch was applied cleanly.

That's the entire point of the reflog.  :-)

-- 
Shawn.

Re: [PATCH 2/2] Allow non-fast-forward of remote tracking branches in default clone

[Shawn Pearce]

Junio C Hamano <junkio@cox.net> wrote:
> This changes the default remote.origin.fetch configuration
> created by git-clone so that it allows non-fast-forward updates.

Ack'd, but only if '[PATCH 1/2] core.logallrefupdates: log remotes/
tracking branches.' is also applied.

I think both are worth applying.

-- 
Shawn.

Re: [PATCH 2/2] Allow non-fast-forward of remote tracking branches in default clone

[Johannes Schindelin]

Hi,

On Thu, 28 Dec 2006, Junio C Hamano wrote:

>  		git-repo-config remote."$origin".fetch \
> -			"refs/heads/*:$remote_top/*" '^$' &&
> +			"+refs/heads/*:$remote_top/*" '^$' &&

Minor nit: these days, it is cleaner (and clearer) to use "git-repo-config 
--add" instead of using the "^$" construct yourself. However, I don't 
think this patch has to be changed.

Ciao,
Dscho