On 2016-05-25 12:00, Martin Kosek wrote: > 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 don't know why github either forces merge commits or a single squashed commit. If I would have to guess, I would assume it has philosophical reasons. It took many years to get github to add an alternative to merge commits. A single commit of a squashed branch is rather similar to a merge commit. >> 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. That makes sense. Christian
Description: OpenPGP digital signature
-- 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