git pull fails

git pull fails

[Timo Hirvonen]

I think fast-forward check in git-fetch is too strict:

28 16:13 /usr/src/git: git pull
Unpacking 33 objects
 100% (33/33) done
* refs/heads/todo: same as branch 'todo' of git://git.kernel.org/pub/scm/git/git
* refs/heads/maint: same as branch 'maint' of git://git.kernel.org/pub/scm/git/git
* refs/heads/origin: same as branch 'master' of git://git.kernel.org/pub/scm/git/git
* refs/heads/pu: does not fast forward to branch 'pu' of git://git.kernel.org/pub/scm/git/git;
  not updating.

After removing "exit 1" added by a9698bb22fb7b66e5882c3a5e7b2b8b53ea03f90 from
git-fetch "git pull" worked again.

-- 
http://onion.dynserv.net/~timo/

Re: git pull fails

[Ralf Baechle]

On Tue, Mar 28, 2006 at 04:28:31PM +0300, Timo Hirvonen wrote:

> I think fast-forward check in git-fetch is too strict:
> 
> 28 16:13 /usr/src/git: git pull
> Unpacking 33 objects
>  100% (33/33) done
> * refs/heads/todo: same as branch 'todo' of git://git.kernel.org/pub/scm/git/git
> * refs/heads/maint: same as branch 'maint' of git://git.kernel.org/pub/scm/git/git
> * refs/heads/origin: same as branch 'master' of git://git.kernel.org/pub/scm/git/git
> * refs/heads/pu: does not fast forward to branch 'pu' of git://git.kernel.org/pub/scm/git/git;
>   not updating.
> 
> After removing "exit 1" added by a9698bb22fb7b66e5882c3a5e7b2b8b53ea03f90 from
> git-fetch "git pull" worked again.

Continuing to walk after breaking a leg isn't a good idea, but that's
basically what your change did.  What has happened to you is the normal
thing with branches that have been re-based or otherwise re-created.
The better way to handle this kind of branches is to add a `+´ sign to
the refspec for the pu branc in .git/remote/origin like:

[ralf@blah git]$ cat .git/remotes/origin
URL: git://www.kernel.org/pub/scm/git/git.git
Pull: master:master
Pull: todo:todo
Pull: +next:next
Pull: maint:maint
Pull: +pu:pu
Pull: html:html
Pull: man:man
[ralf@blah git]$

The next branch is handled the same way, so another `+´ sign.

  Ralf

Re: git pull fails

[Timo Hirvonen]

Ralf Baechle <ralf@linux-mips.org> wrote:

> Continuing to walk after breaking a leg isn't a good idea, but that's
> basically what your change did.  What has happened to you is the normal
> thing with branches that have been re-based or otherwise re-created.
> The better way to handle this kind of branches is to add a `+´ sign to
> the refspec for the pu branc in .git/remote/origin like:
> 
> [ralf@blah git]$ cat .git/remotes/origin
> URL: git://www.kernel.org/pub/scm/git/git.git
> Pull: master:master
> Pull: todo:todo
> Pull: +next:next
> Pull: maint:maint
> Pull: +pu:pu
> Pull: html:html
> Pull: man:man
> [ralf@blah git]$
> 
> The next branch is handled the same way, so another `+´ sign.

Thanks, but forcing everyone to edit their git/remotes/origin file
is not very nice solution.  I think git-fetch should update refs for the
other non-'broken' branches and leave "pu" and "next" refs untouched.

-- 
http://onion.dynserv.net/~timo/

Re: git pull fails

[Radoslaw Szkodzinski]

[-- Attachment #1: Type: text/plain, Size: 1350 bytes --]

On Tuesday 28 March 2006 16:38, Timo Hirvonen wrote yet:
> Thanks, but forcing everyone to edit their git/remotes/origin file
> is not very nice solution.  I think git-fetch should update refs for the
> other non-'broken' branches and leave "pu" and "next" refs untouched.

How do you know a non-broken branch from something weird?
All git knows is that the history is non-linear. You can do at least three 
things:
- discard older history
- merge older history with newer
- add another branch

Or instead provide a more useful error message, like what is attached.
(I hope kmail doesn't mangle the tabs.)

diff --git a/git-fetch.sh b/git-fetch.sh
index 0346d4a..88df7f4 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -172,13 +172,15 @@ fast_forward_local () {
 		;;
 	    esac || {
 		echo >&2 "* $1: does not fast forward to $3;"
+		echo >&2 "  If the branch is known to roll back often,"
+		echo >&2 "  add + before the branch name in $GIT_DIR/$1."
 		case ",$force,$single_force," in
 		*,t,*)
-			echo >&2 "  forcing update."
+			echo >&2 "  Forcing update."
 			git-update-ref "$1" "$2" "$local"
 			;;
 		*)
-			echo >&2 "  not updating."
+			echo >&2 "  Not updating."
 			;;
 		esac
 	    }

-- 
GPG Key id:  0xD1F10BA2
Fingerprint: 96E2 304A B9C4 949A 10A0  9105 9543 0453 D1F1 0BA2

AstralStorm

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: git pull fails

[Petr Baudis]

Dear diary, on Tue, Mar 28, 2006 at 05:00:11PM CEST, I got a letter
where Radoslaw Szkodzinski <astralstorm@o2.pl> said that...
> On Tuesday 28 March 2006 16:38, Timo Hirvonen wrote yet:
> > Thanks, but forcing everyone to edit their git/remotes/origin file
> > is not very nice solution.  I think git-fetch should update refs for the
> > other non-'broken' branches and leave "pu" and "next" refs untouched.
> 
> How do you know a non-broken branch from something weird?

If I understand it right, Timo complains that git-fetch got
non-fastforward commits for "pu" and "next" and a good fastforward
commit for "master", but it didn't update the ref for ANY head, not even
the "master".

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time.  I think
I have forgotten this before.

Re: git pull fails

[Timo Hirvonen]

Petr Baudis <pasky@suse.cz> wrote:

> If I understand it right, Timo complains that git-fetch got
> non-fastforward commits for "pu" and "next" and a good fastforward
> commit for "master", but it didn't update the ref for ANY head, not even
> the "master".

Exactly.  Maybe git-fetch should abort only if it could not update the
currently checked out branch?

-- 
http://onion.dynserv.net/~timo/

Re: git pull fails

[Junio C Hamano]

Timo Hirvonen <tihirvon@gmail.com> writes:

> Petr Baudis <pasky@suse.cz> wrote:
>
>> If I understand it right, Timo complains that git-fetch got
>> non-fastforward commits for "pu" and "next" and a good fastforward
>> commit for "master", but it didn't update the ref for ANY head, not even
>> the "master".
>
> Exactly.  Maybe git-fetch should abort only if it could not update the
> currently checked out branch?

The erroring-out is there so that the user can take notice.

Re: git pull fails

[Petr Baudis]

Dear diary, on Wed, Mar 29, 2006 at 02:11:36AM CEST, I got a letter
where Timo Hirvonen <tihirvon@gmail.com> said that...
> Exactly.  Maybe git-fetch should abort only if it could not update the
> currently checked out branch?

That should _never_ be the case. Any modern porcelain shouldn't let you
switch your current branch to a remote one, hopefully. It's just wrong.
The supported setup is that you have a remote branch reflecting where
the upstream is and a local branch reflecting where your current tree
is, and you update your local branch by git-pull (or git-merge if you
want to avoid fetching).

If your current branch would really be a remote branch and you simply
git-fetched, your HEAD would change but not your working tree, and at
that moment things would become very confusing. Cogito would start
showing nonsensical stuff for cg-status and cg-diff (as well as
git-diff-tree HEAD output), but your index would at least still be
correct so I'm not sure how much attention do tools like git-diff pay to
it, the level of messup would be proportional to that.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time.  I think
I have forgotten this before.

Re: git pull fails

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

> If your current branch would really be a remote branch and you simply
> git-fetched, your HEAD would change but not your working tree, and at
> that moment things would become very confusing. Cogito would start
> showing nonsensical stuff for cg-status and cg-diff (as well as
> git-diff-tree HEAD output), but your index would at least still be
> correct so I'm not sure how much attention do tools like git-diff pay to
> it, the level of messup would be proportional to that.

People want to leave tracking branches checked out, especially
when they are not developers but are "update to the latest and
compile the bleeding edge" types.  Support for that mode of
operation was invented long time ago and git-pull knows about
it, and the idea was ported to git-cvsimport recently.

Re: git pull fails

[Petr Baudis]

Dear diary, on Wed, Mar 29, 2006 at 02:40:30AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Petr Baudis <pasky@suse.cz> writes:
> 
> > If your current branch would really be a remote branch and you simply
> > git-fetched, your HEAD would change but not your working tree, and at
> > that moment things would become very confusing. Cogito would start
> > showing nonsensical stuff for cg-status and cg-diff (as well as
> > git-diff-tree HEAD output), but your index would at least still be
> > correct so I'm not sure how much attention do tools like git-diff pay to
> > it, the level of messup would be proportional to that.
> 
> People want to leave tracking branches checked out, especially
> when they are not developers but are "update to the latest and
> compile the bleeding edge" types.  Support for that mode of
> operation was invented long time ago and git-pull knows about
> it, and the idea was ported to git-cvsimport recently.

Why can't such people just have two branches, _especially_ if they are
the "update to the latest and compile the bleeding edge" types?
(Therefore well not likely to be familiar with the Git branching model
at all.)

I mean, sure, it's Core Git so the extra flexibility is nice. But I now
wonder, can you think of any plausible workflow where having one branch
instead of two would be an advantage?

Waah, cg-log git-fetch.sh, /update-head just showed me the change in
git-fetch-script from last August, with no extra work for me. The big
rename barrier annoyances finally gone forever!

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time.  I think
I have forgotten this before.