One other (long shot) option might be to do git cherry-picks of all new
*trunk* commits into the feature branch when you uprev. But I'm not sure if
that will be a sustainable practice, given the number of commits that are
happening on the trunk. Unless you're upreving very often (e.g. daily),
this
Sounds like we have a lot of support for also allowing merge workflows. Let
me draft a proper proposal and go through the [DISCUSS] and [VOTE] process.
One thing I think we should amend from the previous [VOTE] is using "git
merge --no-ff" rather than "rebase --onto" for branch -> trunk integration
+1, I agree with the support for git-merge based workflows for large branch
merge.
I have experienced the pain of re-basing the entire branch HDFS-7285, just
for verification though, and I found even a line change in trunk in core
files ( ex: FSNameSystem.java, BlockManager.java ) makes it hard to
I also think allowing merges as a way to uprev with trunk would be a good
idea. AFAIK, git rebase works well when your branch is short-lived and
contains a fairly small number of commits, but doesn't work so well if your
branch is large. Also, the cost of rebase will only go up as time goes. On
the
I think we should allow merge-based workflows. I worked and am working in
several big feature branches, including HDFS-2802 (>100 subtasks) and
HDFS-7285 (currently already > 200 subtasks), and tried both the
merge-based and rebase-based workflows. When the feature change becomes
big, the rebase wi
Hi all,
I've thought about this topic more over the last week, and felt I should
play devil's advocate for a merge workflow. A few comments:
- The issue of merges "polluting history" is mainly an issue when using
a github PR workflow, which results in one merge per PR. Clearly this is
no
Thanks for the clarification Andrew.
So is the proposal on the table squashing commits (on the feature branch)
when we rebase the feature branch with the latest from trunk? How would the
process work? A simple schematic example might be helpful in understanding
the proposal. If the feature branch
@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 che
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
wrote:
> I haven't done a bit piece of wo
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
I prefer Proposal #1 as well. Squashing some of the commits seems a major
improvement over our previous model of a single commit for the entire
branch.
On Tue, Aug 11, 2015 at 2:19 PM, Andrew Wang
wrote:
> Hi all,
>
> We are currently working on a pretty substantial new feature in a branch
> ove
Hi all,
We are currently working on a pretty substantial new feature in a branch
over at HDFS-7285. As the # of commits has grown, running `git rebase` and
fixing conflicts in the 180+ commits has become untenable. As you may
recall, we voted to use a rebase workflow when we did the switch from SV
12 matches
Mail list logo
