git pull fails

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.

On Tue, Mar 28, 2006 at 04:28:31PM +0300, Timo Hirvonen 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.

  Ralf

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

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.

On Tuesday 28 March 2006 16:38, Timo Hirvonen wrote yet:

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

Dear diary, on Tue, Mar 28, 2006 at 05:00:11PM CEST, I got a letter where Radoslaw Szkodzinski <astralstorm@o2.pl> said that...

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 Baudis <pasky@suse.cz> wrote:

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

Timo Hirvonen <tihirvon@gmail.com> writes:

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

Dear diary, on Wed, Mar 29, 2006 at 02:11:36AM CEST, I got a letter where Timo Hirvonen <tihirvon@gmail.com> said that...

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 Baudis <pasky@suse.cz> writes:

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.

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

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!