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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
