Mailing-List: contact common-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-dev@hadoop.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CADbBEnsrNF-K1U1Y78GA=OqzEbs8nZOgah13kg0ev9t0muS_5Q@mail.gmail.com>
References: 
 <CAGB5D2bPWeV2Hk+67=DamWpVfLTM6nkjb_wG3n4=WAN890zqfA@mail.gmail.com>
 <CALwhT95ZLjvDb33L1pkMgLG8B=hm3O_CDhg4u=ULXz9oq6RG-w@mail.gmail.com>
 <ACB0CC88-56CE-49EB-B534-6E4D0DF89B87@hortonworks.com>
 <CADbBEnsrNF-K1U1Y78GA=OqzEbs8nZOgah13kg0ev9t0muS_5Q@mail.gmail.com>
From: Andrew Wang <andrew.wang@cloudera.com>
Date: Mon, 17 Aug 2015 11:33:26 -0700
Message-ID: 
 <CAGB5D2awiaQWN+5=dS1chaOsS5h=TwsiHG6iadjfxF7Gnn_QeA@mail.gmail.com>
Subject: Re: [DISCUSS] git rebase vs. git merge for branch development
To: "common-dev@hadoop.apache.org" <common-dev@hadoop.apache.org>
Content-Type: multipart/alternative; boundary=001a114fcc5ab19a3f051d860afa

--001a114fcc5ab19a3f051d860afa
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

@Sangjin,

I believe this is covered by the [VOTE] I linked to above, key excerpt
being:

   3. Force-push on feature-branches is allowed. Before pulling in a
   feature, the feature-branch should be rebased on latest trunk and the
   changes applied to trunk through "git rebase --onto" or "git cherry-pick
   <commit-range>".

This specifies that the last uprev final integration of the branch
into trunk happen with rebase. It doesn't say anything about the
periodic uprev's, but it'd be very strange to merge periodically and
then rebase once at the end. So I take it to mean doing periodic
uprevs with rebase too.


On Mon, Aug 17, 2015 at 11:23 AM, Sangjin Lee <sjlee@apache.org> wrote:

> Just to be clear, are we discussing the process of uprev'ing the feature
> development branch with the latest from the trunk from time to time, or
> making the final merge of the feature branch onto the trunk?
>
> On Mon, Aug 17, 2015 at 10:21 AM, Steve Loughran <stevel@hortonworks.com>
> wrote:
>
> > I haven't done a bit piece of work in the ASF code repo since the
> > migration to git; though I have done it in the svn era.
> >
> >
> > Currently with private git repos
> > -anyone gets SCM control of their source
> > -you can commit for your own reasons (about to make a change, want a
> > private jenkins run, ...) and gain from having many small checkins. Mor=
e
> > succinctly: if you aren't checking in your work 2+ times a day =E2=80=
=94why not?
> > -rebasing a painful necessity on personal, private branches to keep the
> > final patch to hadoop git a single diff
> >
> > With the private git process that's the defacto standard, we lose histo=
ry
> > anyway. I know what I've done and somewhere there's a tag in my own
> github
> > repo of my work to create a JIRA. But we don't always need that entire
> > history of "trying to debug kerberos", "typo in exception", and other
> stuff
> > that accrues during the work.
> >
> > I think therefore that I'm in favour of big squash commits. What we cou=
ld
> > do is extend that with a policy of
> >
> >
> >   1.  tag the final commit used to make the patch, something like
> > tag_HADOOP-8192. The tag ensures that the history isn't gc'd
> >   2.  Delete the branch (keeps the #of branches down)
> >   3.  In the JIRA, include the name of the tag and the git commit numbe=
r
> > in the comments. Someone curious can rebuild that history
> >
> >
>

--001a114fcc5ab19a3f051d860afa--