Subject: Re: What's cooking in git.git (topics)

From: "J. Bruce Fields" <[email-masked]>
Date: Mon, 26 Nov 2007 04:45:38 +0000

On Sun, Nov 25, 2007 at 11:29:56PM -0500, Nicolas Pitre wrote:
> On Mon, 26 Nov 2007, J. Bruce Fields wrote:
> 
> > I do find that trying to work on top of a constantly rebased branch is
> > annoying no matter how I do it.  So I sometimes wonder if we shouldn't
> > instead be finding ways to avoid the practice.
> 
> I don't think it can't be avoided in many cases.  Some stuff gets 
> rebased because it has to be refined before it is merged in a more 
> stable and more "official" repository.

Well, there is for example the option of doing things like:

	git checkout -b new-mywork mywork
	git fetch origin
	git rebase new-mywork origin
	# further reordering of commits, etc., as needed
	git merge -s ours mywork
	git branch -d mywork
	git push mypubrepo new-mywork:mywork

and if you do this each time, then the public branch named "mywork"
always fast-forwards.  Its first parent, mywork^, is always a clean
patch series against upstream, and is what you'll eventually submit.
The second parent leads to historical versions of the patch series.

> Working on top of a rebased 
> branch could be much easier if there was a dedicated command to perform 
> the local rebase of one's work after a fetch, just like the pull command 
> does a merge after a fetch, at which point both work flows would be 
> almost equivalent wrt ease of use.

I don't think that works if you have more than one branch built on top
of the branch you're fetching.

The problem is that you have to do the rebase at the same time as the
fetch, because it's only the fetch that knows what the old head of the
branch was.

You don't need to know what the old head of the branch was before if
you're fetching a branch that always fast-forwards.  But you do in the
case where it doesn't fast-forward, because in that case the old head
will be forgotten as soon as you're done.

--b.