Re: [Freeipa-devel] Questions on git
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
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
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
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
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
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
