12:31 a.m.
Since this is the second time I'm facing the same dillema, I think it's
worthwhile to discuss this here.
We have been doing the --no-ff merges for everything, but I just found
two cases where I really think we should stick to fast-forward merges:
single-commit PRs and PRs to feature branches.
Thoughts on this? Any other comments/suggestions wrt git workflows we
use?
--
qmx
1:48 a.m.
we should stick to fast-forward merges:single-commit PRs and PRs to
feature branches.
+1 Sounds good to me.
On 22 July 2013 07:31, Douglas Campos <qmx(a)qmx.me> wrote:
Since this is the second time I'm facing the same dillema, I
think it's
worthwhile to discuss this here.
We have been doing the --no-ff merges for everything, but I just found
two cases where I really think we should stick to fast-forward merges:
single-commit PRs and PRs to feature branches.
Thoughts on this? Any other comments/suggestions wrt git workflows we
use?
--
qmx
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
6:40 a.m.
I'll just take this as an opportunity to once again say I hate merge commits and thus,
I hate --no-ff in all cases.
</rant>
On Jul 22, 2013, at 12:31 AM, Douglas Campos <qmx(a)qmx.me> wrote:
Since this is the second time I'm facing the same dillema, I
think it's
worthwhile to discuss this here.
We have been doing the --no-ff merges for everything, but I just found
two cases where I really think we should stick to fast-forward merges:
single-commit PRs and PRs to feature branches.
Thoughts on this? Any other comments/suggestions wrt git workflows we
use?
--
qmx
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
6:56 a.m.
On Mon, 22 Jul 2013 06:40:18 -0500
Kris Borchers <kris(a)redhat.com> wrote:
I'll just take this as an opportunity to once again say I hate
merge commits
and thus, I hate --no-ff in all cases.
</rant>
Same here.
That said, ff merge for single commits and for PRs to feature
branches policy could cover all PRs if squashed first ;-)
On Jul 22, 2013, at 12:31 AM, Douglas Campos <qmx(a)qmx.me> wrote:
> Since this is the second time I'm facing the same dillema, I think it's
> worthwhile to discuss this here.
>
> We have been doing the --no-ff merges for everything, but I just found
> two cases where I really think we should stick to fast-forward merges:
> single-commit PRs and PRs to feature branches.
>
> Thoughts on this? Any other comments/suggestions wrt git workflows we
> use?
>
> --
> qmx
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
8:18 a.m.
On Mon, Jul 22, 2013 at 01:56:31PM +0200, Karel Piwko wrote:
On Mon, 22 Jul 2013 06:40:18 -0500
Kris Borchers <kris(a)redhat.com> wrote:
> I'll just take this as an opportunity to once again say I hate merge commits
> and thus, I hate --no-ff in all cases.
>
> </rant>
Same here.
That said, ff merge for single commits and for PRs to feature
branches policy could cover all PRs if squashed first ;-)
Then you lose history +
end up with gigantic commits with unrelated
changes - been there unfortunately.
--
qmx
7:11 a.m.
huh, i didn't know we had a policy, i was always assuming that merge commits were
bad
On Jul 22, 2013, at 7:40 AM, Kris Borchers <kris(a)redhat.com> wrote:
I'll just take this as an opportunity to once again say I hate
merge commits and thus, I hate --no-ff in all cases.
</rant>
On Jul 22, 2013, at 12:31 AM, Douglas Campos <qmx(a)qmx.me> wrote:
> Since this is the second time I'm facing the same dillema, I think it's
> worthwhile to discuss this here.
>
> We have been doing the --no-ff merges for everything, but I just found
> two cases where I really think we should stick to fast-forward merges:
> single-commit PRs and PRs to feature branches.
>
> Thoughts on this? Any other comments/suggestions wrt git workflows we
> use?
>
> --
> qmx
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
8:15 a.m.
On Mon, Jul 22, 2013 at 06:40:18AM -0500, Kris Borchers wrote:
I'll just take this as an opportunity to once again say I hate
merge
commits and thus, I hate --no-ff in all cases.
you could scream "I told
ya" instead :P
We need to find a compromise - going all --no-ff has drawbacks,
squashing has them too (gigantic commits)
--
qmx
11:21 a.m.
TBH, I always make sure the PR is rebased then merge and there is no merge commit and no
lost history. Sure, sometimes conflicts have to be resolved but that has to be done one
way or another.
On Jul 22, 2013, at 8:28 AM, "Heiko W.Rupp" <hrupp(a)redhat.com> wrote:
Am 22.07.2013 um 15:15 schrieb Douglas Campos:
> squashing has them too (gigantic commits)
Much better than a huge merge / rebase with hundreds of individual
commits, perhaps even changing the same line of code a dozen
times.
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
1:45 p.m.
I think mixed approach is best. We had "straight line / no merging commits" and
"squash everything into few nice commits" policy - works great for bug fixes and
PRs up to few commits. Then we realize that in case of serious feature related topic
branch it is just sad to squash and lose a history - also don't give credit to
everyone involved. Still good to cleanup the branch before doing a PR... All in all I
personally think that such policies should be loose...
----- Original Message -----
From: "Kris Borchers" <kris(a)redhat.com>
To: "AeroGear Developer Mailing List" <aerogear-dev(a)lists.jboss.org>
Sent: Monday, July 22, 2013 6:21:15 PM
Subject: Re: [aerogear-dev] Git Merge Policy Review
TBH, I always make sure the PR is rebased then merge and there is no merge commit and no
lost history. Sure, sometimes conflicts have to be resolved but that has to be done one
way or another.
On Jul 22, 2013, at 8:28 AM, "Heiko W.Rupp" <hrupp(a)redhat.com> wrote:
Am 22.07.2013 um 15:15 schrieb Douglas Campos:
> squashing has them too (gigantic commits)
Much better than a huge merge / rebase with hundreds of individual
commits, perhaps even changing the same line of code a dozen
times.
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
11:34 p.m.
On Thu, Jul 25, 2013 at 02:45:38PM -0400, Boleslaw Dawidowicz wrote:
I think mixed approach is best. We had "straight line / no
merging
commits" and "squash everything into few nice commits" policy - works
great for bug fixes and PRs up to few commits. Then we realize that in
case of serious feature related topic branch it is just sad to squash
and lose a history - also don't give credit to everyone involved.
Still good to cleanup the branch before doing a PR... All in all I
personally think that such policies should be loose...
That's exactly what this
thread proposed - we were strict in losing no
commits/always doing merge commits, so relaxing it a little bit.
--
qmx
8:06 a.m.
I've been doing --no-ff to merge PRs, even if they have a single commit
or they are feature branches. Do we have a policy for it?
Once we have a very well defined policy (e-mail, piece of papers or
whatever), I have no problems on change it.
Douglas Campos wrote:
Since this is the second time I'm facing the same dillema, I
think it's
worthwhile to discuss this here.
We have been doing the --no-ff merges for everything, but I just found
two cases where I really think we should stick to fast-forward merges:
single-commit PRs and PRs to feature branches.
Thoughts on this? Any other comments/suggestions wrt git workflows we
use?
--
abstractj
8:08 a.m.
On 07/22/2013 01:31 AM, Douglas Campos wrote:
Since this is the second time I'm facing the same dillema, I
think it's
worthwhile to discuss this here.
We have been doing the --no-ff merges for everything, but I just found
two cases where I really think we should stick to fast-forward merges:
single-commit PRs and PRs to feature branches.
Thoughts on this? Any other comments/suggestions wrt git workflows we
use?
If it is a single commit PR to master I kinda like have a single word
description from the branch name if it is anything more than an
extremely minor change.
So +.9 to single commit no ff and +1 to prs to feature branches.
4154
days inactive
4161
days old
13 comments
9 participants
participants (9)
-
Boleslaw Dawidowicz -
Bruno Oliveira -
Daniel Bevenius -
Douglas Campos -
Heiko W.Rupp -
Karel Piwko -
Kris Borchers -
Lucas Holmquist -
Summers Pittman