Hi,
On Sat, 21 Jul 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
>
> >> Two questions and a half.
> >>
> >> - The above means git-gui-i18n.git's master is rebased. Is
> >> that the intention? IOW, people are supposed to work on it
> >> with fetch+rebase, not fetch+merge (= pull)?
> >
> > Okay, you have me there. Usually I am the one saying "rebasing is bad".
> > So I'll refrain from that practice. From now on, 'master' will _not_ be
> > rebased. From time to time I will prepare 'for-shawn' branches, which are
> > "master rebased onto git-gui".
>
> I did not mean to say "rebase is bad". Quite the contrary.
Yeah, I was not really precise. Rebase is only bad for branches that want
to be tracked.
As you can see from my work on rebase -i, I recently converted to an avid
user of rebase, from somebody who detested the feature a year ago.
> [...] I think it would be a reasonable and manageable workflow to:
>
> - people fork from 'mob', push back to 'mob';
>
> - you
> - build 'master' by cherry picking good bits from 'mob', and
> - do your own fixups and framework changes on 'master',
> - merge 'master' back to 'mob' to allow contributors to
> adjust their work on the updated 'master' by simply
> following 'mob',
>
> - and eventually clean-up 'master' to make it mergeable and/or
> applicable to git-gui itself.
I plan to pull and push from mob, from time to time
cherry-picking/rebasing and cleaning up to a branch called 'for-shawn'.
To keep things a little synchronised, I plan to make grafts at stages
where master^{tree} = for-shawn^{tree}, so that rebase is easier.
Ciao,
Dscho
-
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
