You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nifi.apache.org by Joe Skora <js...@gmail.com> on 2015/11/04 14:15:25 UTC
Gitting the hub right
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
Re: Gitting the hub right
Posted by Aldrin Piri <al...@gmail.com>.
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 <bb...@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
> > >>
> > >>
> > >>
> >
> >
>
Re: Gitting the hub right
Posted by Bryan Bende <bb...@gmail.com>.
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 <tr...@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 <js...@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
> >>
> >>
> >>
>
>
Re: Gitting the hub right
Posted by Oleg Zhurakousky <oz...@hortonworks.com>.
“. . .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 <tr...@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 <js...@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
>>
>>
>>
Re: Gitting the hub right
Posted by Tony Kurc <tr...@gmail.com>.
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 <js...@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
>
>
>
Re: Gitting the hub right
Posted by Oleg Zhurakousky <oz...@hortonworks.com>.
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 <bb...@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 <js...@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
Re: Gitting the hub right
Posted by Bryan Bende <bb...@gmail.com>.
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 <js...@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
>
Re: Gitting the hub right
Posted by Oleg Zhurakousky <oz...@hortonworks.com>.
Joe
I think you are referring to ‘squishing’ - https://ariejan.net/2011/07/05/git-squash-your-latests-commits-into-one/
Is that correct or were you asking about something else?
Oleg
On Nov 4, 2015, at 8:15 AM, Joe Skora <js...@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