Re: [Freeipa-devel] Questions on git

2016-05-25 Thread Jan Pazdziora
On Wed, May 25, 2016 at 12:17:18PM +0200, Christian Heimes wrote:
> 
> 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

The reason I was given when discussing it with a GitHub person was
that it's a performance issue. They are worried that people would use
it for multi-hundred-commit branches and the WebUI would not be able
to provide the same fast response as for single diff/commit.

-- 
Jan Pazdziora
Senior Principal Software Engineer, Identity Management Engineering, Red Hat

-- 
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


Re: [Freeipa-devel] Questions on git

2016-05-25 Thread 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




signature.asc
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

Re: [Freeipa-devel] Questions on git

2016-05-25 Thread Martin Kosek
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


Re: [Freeipa-devel] Questions on git

2016-05-25 Thread Christian Heimes
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/

I guess we can use squashed merges for the majority of simple PRs.

Christian




signature.asc
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

Re: [Freeipa-devel] Questions on git

2016-05-25 Thread Martin Kosek
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:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code


Re: [Freeipa-devel] Questions on git

2016-05-23 Thread Jakub Hrozek
On Mon, May 23, 2016 at 04:33:29PM +0200, Martin Basti wrote:
> 
> 
> On 23.05.2016 16:24, Florence Blanc-Renaud wrote:
> > Hi all,
> > 
> > as I am ramping up with git, I have a few questions. Let's imagine the
> > following development workflow:
> > 
> > - 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
> > - When my code looks ok, I decide to commit on the branch (still on my
> > ldaptop)
> > git add 
> > git commit
> 
> I found handy also 'git add -p' which allows you to choose what commit

...or git add -e

> 
> > 
> > - Now I would like to push this on my development VM (I already cloned
> > the repos on the VM). What would be the right command to push only the
> > branch "issue" to my VM repo? Does the following command push only the
> > current branch?
> > git push --repo=ssh://frenaud@:/path/to/src/freeipa
> 
> Could work, I usually just rsync the whole folder to VM

For local VMs, I use an NFS share so that I don't rsync anything, but
the sources magically appear in the VMs (vagrant's shared folders make
this easy once you're past the initial setup pain).

> > 
> > - 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?
> 
> You can stay on your issue branch, but patch should be rebased to current
> master (patch should apply on top of master)
> 
> something like:
> 
> git checkout master
> git pull
> git check issue
> git rebase master issue
> 
> or interactive rebase if you want change order of patches or something
> git rebase -i master issue

IMO creating the branch with "--track origin/master" helps..

btw I find this man page helpful:
https://www.kernel.org/pub/software/scm/git/docs/giteveryday.html
as well as this free book:
https://git-scm.com/book/en/v2

-- 
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


Re: [Freeipa-devel] Questions on git

2016-05-23 Thread Martin Basti



On 23.05.2016 16:24, Florence Blanc-Renaud wrote:

Hi all,

as I am ramping up with git, I have a few questions. Let's imagine the 
following development workflow:


- 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
- When my code looks ok, I decide to commit on the branch (still on my 
ldaptop)

git add 
git commit


I found handy also 'git add -p' which allows you to choose what commit



- Now I would like to push this on my development VM (I already cloned 
the repos on the VM). What would be the right command to push only the 
branch "issue" to my VM repo? Does the following command push only the 
current branch?

git push --repo=ssh://frenaud@:/path/to/src/freeipa


Could work, I usually just rsync the whole folder to VM


- 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?


You can stay on your issue branch, but patch should be rebased to 
current master (patch should apply on top of master)


something like:

git checkout master
git pull
git check issue
git rebase master issue

or interactive rebase if you want change order of patches or something
git rebase -i master issue


Thanks for your tips,
Flo.
--
Florence Blanc-Renaud
Identity Management Team, Red Hat




Martin^2
-- 
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

[Freeipa-devel] Questions on git

2016-05-23 Thread Florence Blanc-Renaud

Hi all,

as I am ramping up with git, I have a few questions. Let's imagine the 
following development workflow:


- 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
- When my code looks ok, I decide to commit on the branch (still on my 
ldaptop)

git add 
git commit

- Now I would like to push this on my development VM (I already cloned 
the repos on the VM). What would be the right command to push only the 
branch "issue" to my VM repo? Does the following command push only the 
current branch?

git push --repo=ssh://frenaud@:/path/to/src/freeipa

- 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?


Thanks for your tips,
Flo.

--
Florence Blanc-Renaud
Identity Management Team, Red Hat

-- 
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