6:09 a.m.
Hi,
My suggestion of the use of squash for some scenarios comes from our experience with
GateIn/Portal:
https://github.com/gatein/gatein-portal/commits/master
I'm not talking about granularity.
I'm +1 to have a PR with non-squash for a review, but once consolidated, a squash can
help to have a better organized history (i.e. marked with a JIRA/Bugzilla related to the
task involved).
And I admit that there are situations where squashing has not sense.
But the project is growing and it's good to have some "grouping" with some
logical background about what feature/fix/patch is related.
Just my 2 cents.
----- Original Message -----
From: "Lukas Krejci" <lkrejci(a)redhat.com>
To: "Discussions around Hawkular development"
<hawkular-dev(a)lists.jboss.org>
Sent: Thursday, May 28, 2015 12:58:50 PM
Subject: Re: [Hawkular-dev] [process] tickets and PRs
On Thursday, May 28, 2015 12:50:55 Lukas Krejci wrote:
> On Wednesday, May 27, 2015 12:46:29 Juraci Paixão Kröhling wrote:
> > On 05/27/2015 12:41 PM, Lucas Ponce wrote:
> > > I also propose to squash commits when it has sense.
> >
> > +1 , having "one commit per jira" helps a lot in debugging :-)
>
btw. if you want to figure out how a certain commit got merged into the
master, you can use:
git log <COMMIT_HASH>..master --ancestry-path --merges
or
https://github.com/mhagger/git-when-merged
> -1 on squashing all PRs (if that is what you meant).
>
> IMHO squashes are a nice feature to get rid of "garbage" commits PRIOR to
> pushing those commits upstream but SHOULD NOT be used to modify any commits
> that exists also remotely.
>
> There are at least 4 reasons against squashing, IMHO:
>
> 1) possibility of messing things up like Mazz described.
> 2) divergence of histories in different repos (git branch|tag --contains
> ceases to work)
> 3) squashing a large PR renders bisecting useless
> 4) it makes it impossible to "follow" a history of a feature development
>
> So I agree that it makes sense to squash certain commits, but only before
> they are merged into the official repos.
>
> Ideally I think squash should only be used on local commits. But I do
> recognize that one may just push stuff to their personal forks that they
> later on would like to modify the history of (i.e. you're working on
> something and either push quickly commits you didn't "clean out"
locally or
> change your mind later about something and don't want to "pollute"
upstream
> with commits going back and forth on the same lines of code).
>
> So IMHO a) the number of commits for a jira should be proportional to the
> size of the change and b) the commit history should be finalized before
> merging the PR and retained using the merge of the PR.
>
> > - Juca.
> >
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev