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.
Rebase is bad for a repository meant for public consumption of
the under-development-snapshot, like git.git's 'master' and
'next'. For a repository like git-gui-i18n whose sole point is
to serve as a public gathering point of narrowly focused area of
development (only translation of messages), I actually think
"everybody fetches and rebases" workflow is perfectly fine, as
long as all participants understand what the expected workflows
are. My comment was more about making it clear what the policy
is to its intended audience.
Rebasing git-gui-i18n to keep its history clean would eventually
allow you to merge it directly into git-gui. But if you are not
aiming for that (and you said your plan is to cherry pick the
result, not to merge, which is fine), then rebasing would no buy
you anything, so 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.
-
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
