Re: nicer frontend to get rebased tree?

[Jakub Narebski <jnareb@gmail.com>]

Andi Kleen <andi@firstfloor.org> writes:

> On Fri, Aug 22, 2008 at 01:56:39PM -0400, Avery Pennarun wrote:
> > On Fri, Aug 22, 2008 at 1:46 PM, Andi Kleen <andi@firstfloor.org> wrote:

> > > But I presume that's a reasonable common usage. Would it
> > > make sense to have some standard git sub command that does that?
> > > ("get latest state of remote branch, doing what it takes to get it")
> > > Or is there already one that I missed?
> > 
> > Isn't that just
> > 
> >     git fetch somewhere branchname
> >     git reset --hard FETCH_HEAD
> > 
> > ?
> 
> My script right now does.
> 
> git fetch origin
> git fetch --tags origin
> git remote update
> git checkout master
> git reset --hard origin/master
> 
> Sure I can continue using the script (until some change breaks it %),
> but I was just asking if that was a common enough operation to deserve
> some better support in standard git. It personally (as a relatively
> inexperienced git user) took me some time to come up with
> this script and I found the original behaviour of git pull on rebased
> trees double-plus unintuitive.
> 
> Just an idea for improvement.

With new enough git it should be enough to do

  $ git fetch origin
  $ git checkout origin/master      # detaches HEAD

OR

  $ git remote update
  $ git reset --hard origin/master  # when on master

BTW. it is stated countless time in documentation that published
history should be not rebased, barring some extenuating circumstances
(liku Junio's 'pu' (proposed updates) branch in git repository).
-- 
Jakub Narebski
Poland
ShadeHawk on #git