On 05/25/2016 10:03 AM, Jan Pazdziora wrote:
> On Mon, May 23, 2016 at 04:24:38PM +0200, Florence Blanc-Renaud wrote:
>> - I start working on a specific issue and decide to create a branch on my
>> git repository (on my laptop)
>> git clone git://git.fedorahosted.org/git/freeipa.git
>> git branch -b issue
> This likely needs to be
>      git checkout -b issue
>> - When the tests are ok and I want to submit a patch, can I stay on the
>> branch "issue" to create the patch or should I merge first with the main
>> branch? If a merge is required, is it recommended to pull then merge or
>> merge then pull?
> As mentioned by Martin, you are looking for rebase, not merge. Rebase
> will re-create commits from the branch on top of other branch (master,
> most likely), omitting changes that got to master in the mean time,
> and giving you chance to resolve conflicts with whatever other changes
> might have gone to master, so that others have as clean experience as
> possible.
> If you look at FreeIPA's history (I like gitk for that), you will see
> that merge commits are very rarely used. The reason for keeping the
> history linear (and thus rebasing on master often) is that it forces
> the author to be explicit about the diffs, plus git tools for
> introspecting history often choke on parallel branches that get
> merged.

+1, we want to keep that. For example, even though we already had some
discussions about adopting github workflow (pull reuqests) as the main vehicle
for patch reviews, we would still prefer to avoid merging and keep rebasing -
the history is much cleaner that way.

Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to