nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Bende <bbe...@gmail.com>
Subject Re: Gitting the hub right
Date Wed, 04 Nov 2015 14:18:58 GMT
Oleg and Tony bring up good points. I'm wondering if we should add
something to the contributor guide about the recommended approach for
updating your pull request when addressing feedback?

Right now the rebase approach that is outlined is more geared towards
leading up to submitting the pull request, or working on a local branch and
generating patches. I think it would be something like...

1) Make changes in your local feature branch to address feedback
2) Push to remote which updates the pull request
3) Repeat steps 1&2 until consensus +1 is given
4) If branch is not readily mergable into master, then do a final rebase
and force push??

Alternatively you could be merging in the latest from master while making
updates, but personally I think it is easiest to review a pull request when
only the commits for that feature are present.

Thoughts?


On Wed, Nov 4, 2015 at 9:16 AM, Oleg Zhurakousky <
ozhurakousky@hortonworks.com> wrote:

> “. . .I prefer doing it by hand in an editor, some part of me gets joy out
> of deleting
> <<<<<'s, ====='s, and >>>>>>'s. I'm not sure what others
do. . ."
>
> same here ;)
>
> > On Nov 4, 2015, at 8:58 AM, Tony Kurc <trkurc@gmail.com> wrote:
> >
> > Regardless of if you're using merge or rebasing then merge (rebasing is
> > nice because then you can generally fast-forward merge to your targeted
> > branch) generally conflicts arise. Getting used to some tool for managing
> > merge conflicts is very important in distributed development. I prefer
> > doing it by hand in an editor, some part of me gets joy out of deleting
> > <<<<<'s, ====='s, and >>>>>>'s. I'm not sure what
others do.
> >
> > I just get in the habit of fetching and rebasing, then merges are not
> > generally so major.
> >
> > A command which is really useful is rebase -i. It allows you to
> > interactively decide how to apply commits, squashing them, changing
> commit
> > messages.
> >
> > Keep in mind with rebase that (especially if you are working with someone
> > else on a branch) you've rewritten history. If you have your commits
> pushed
> > to a remote, if someone else was working on your branch, you sort of
> pulled
> > a rug out from them.
> >
> > To keep my github mirror up to date, I tend to periodically git fetch
> > origin, git checkout master, git merge origin/master (should just be fast
> > forwards here!), git push mirror master  (where origin is apache/nifi and
> > mirror is trkurc/nifi)
> >
> >
> > On Wed, Nov 4, 2015 at 8:39 AM, Oleg Zhurakousky <
> > ozhurakousky@hortonworks.com> wrote:
> >
> >> Just to add to Bryan’s point, here is a more detailed writeup of
> Git-stuff
> >> that I use for my other project, but the approach is identical to the
> one I
> >> use with NiFi -
> >> https://github.com/hortonworks/dstream/wiki/Contributor-Guidelines
> >>
> >> On Nov 4, 2015, at 8:32 AM, Bryan Bende <bbende@gmail.com<mailto:
> >> bbende@gmail.com>> wrote:
> >>
> >> Joe,
> >>
> >> One way to avoid the merge commits is to use rebase. I believe we have
> it
> >> outlined here:
> >>
> >>
> >>
> https://cwiki.apache.org/confluence/display/NIFI/Contributor+Guide#ContributorGuide-Keepingyourfeaturebranchcurrent
> >>
> >> In short, you basically...
> >> - checkout your master
> >> - fetch upstream to get the latest apache nifi master
> >> - merge the upstream master to your master
> >> - checkout your feature branch
> >> - rebase your feature branch to your master, which essentially takes
> away
> >> your commits on that branch, brings it up to date with master, and puts
> >> back your commits
> >>
> >> -Bryan
> >>
> >>
> >> On Wed, Nov 4, 2015 at 8:15 AM, Joe Skora <jskora@gmail.com> wrote:
> >>
> >> Ok, I've read numerous Github howto's, but still don't feel like I've
> been
> >> doing it quite right.
> >>
> >> Assuming that I've cloned the 'apache/nifi' to 'myname/nifi', what is
> the
> >> best way to integrate changes in 'apache/nifi'?  Whatever process I've
> >> followed so far has created another commit in my repo related to merging
> >> the upstream changes, which confuses things when comparing my repo to
> >> upstream.
> >>
> >> Regards,
> >> Joe
> >>
> >>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message