Re: merge errors on 'everything'

[bruno randolf <bruno@thinktube.com>]

On Friday 11 January 2008 00:34:35 John W. Linville wrote:
> On Thu, Jan 10, 2008 at 10:29:44AM +0900, bruno randolf wrote:
> > On Wednesday 09 January 2008 18:05:26 Kalle Valo wrote:
> > > Pavel Roskin <proski@gnu.org> writes:
> > > >> You'll need to get a fresh clone of the repository -- sorry.
> > > >
> > > > While it's reassuring to see that I'm not missing some elegant
> > > > solution, I think cloning the repository is a major overkill.
> > >
> > > I agree.
> > >
> > > > "git-reset --hard origin/everything" does the trick for me, while
> > > > using much less bandwidth and time.
> > >
> > > I do the same and it has worked for me, at least.
> >
> > thanks for that hint, but still, that sucks if you want to rebase your
> > local work against an updated 'everything'...
> >
> > how do you guys manage your pending patches and local work then?
>
> What I recommend is that you start with your own branch from
> 'everything':
>
> 	git checkout -b work everything
>
> And for convenience, create another branch representing where you
> started:
>
> 	git branch work-start
>
> Now do whatever work you want to do on that branch.  You can continue
> to pull into everything as you like (remember to 'git checkout
> everything' first) -- I generally try to preserve a continuous
> everything branch between -rc releases.  So long as the pull is clean,
> you can rebase your work branch quite easily:
>
> 	git checkout work
> 	git rebase everything
>
> 	# don't forget to move work-start as well
> 	git branch -D work-start
> 	git branch work-start everything
>
> After a rebase of wireless-2.6#everything, you won't have a clean pull
> (as you have observed).  In that case you can reclone (be sure to
> save the old clone!) or use git-reset as described above.  Then you
> can use some simple commands to rebase the patches:
>
> 	git checkout -b new-work everything
> 	git branch new-work-start
>
> 	git format-patch --stdout work-start..work > work.mbox
> 	git am work.mbox
>
> An alternative to the git-format-patch/git-am combination would be
> to use the attached 'rangepick' script.
>
> Hth!
>
> John
>
> P.S.  I have no experience with StGit -- some have said it is
> functionaly similar to what I describe above yet perhaps simpler
> to use...YMMV.

thanks for that! i tried StGIT and it works fine for me, also since i usually 
have to fixup my patches several times before i send them and it can do that 
nicely too.

bruno