[Freeipa-devel] Questions on git

[Christian Heimes]

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20160525/54f2a2f8/attachment.sig>