On 05/25/2016 11:55 AM, Christian Heimes wrote: > On 2016-05-25 11:46, Martin Kosek wrote: >> 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. > > +1 against merge commits > > A couple of months ago github introduced a new option. The green merge > button can be configured to either do a merge commit, squash all commits > in the branch or both. > https://help.github.com/articles/about-pull-request-merge-squashing/
Interesting. Do you know why github forces the squashing? It would be better if we can simply have the commits rebased and applied to master branch. > I guess we can use squashed merges for the majority of simple PRs. I expect we will anyway end up with extending "ipatool push" command to do some magic with github API, Trac and Bugzilla as we are used now. Except that it won't accept list of patches in file, but rathe a link/PR number. But this is of course up to dicsussion. Martin -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
