Re: git pull fails

[Petr Baudis <pasky@suse.cz>]

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.