nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aldrin Piri <aldrinp...@gmail.com>
Subject Re: Gitting the hub right
Date Wed, 04 Nov 2015 14:33:48 GMT
Bryan,

Think it is definitely helpful to have.

In general, for other Github endeavors I do a branch on my fork and then
rebase and change history on that branch as needed. GitHub has been quite
good with detecting these changes for the PRs that are open as they evolve
and change.


Aldrin Piri

Sent from my mobile device.

On Wednesday, November 4, 2015, Bryan Bende <bbende@gmail.com> wrote:

> 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 <javascript:;>> 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 <javascript:;>>
> 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 <javascript:;>> 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
> <javascript:;><mailto:
> > >> bbende@gmail.com <javascript:;>>> 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
> <javascript:;>> 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