From: Nicolas Palix <npalix@diku.dk>
To: kernel-janitors@vger.kernel.org
Subject: Re: Keeping up to date with the upstream
Date: Tue, 06 Jul 2010 08:28:59 +0000 [thread overview]
Message-ID: <201007061029.00055.npalix@diku.dk> (raw)
In-Reply-To: <1278362590.5396.35.camel@dermezel>
On Monday 05 July 2010 23:44:18 Joe Eloff wrote:
> On Mon, 2010-07-05 at 23:37 +0200, Peter Hüwe wrote:
> > Am Montag 05 Juli 2010 23:11:22 schrieben Sie:
> > > So if I understand you correctly should finish my patching first on my
> > > current branch then checkout master and git reset --hard origin and do
> > > clean up then go on with something else as obviously those patches will
> > > not be in and the work I have done is now the patch.
> > >
> > > And then from now on just make patches on the master and not worry about
> > > branches since I will keep up to date with the upstream anyway, must
> > > just make sure I have created my patches before syncing the upstream as
> > > to not loose the work I have done.
> >
> >
> > That's at least how I handle the linux-next tree for my buildfailure fixes.
> > I'm not sure if it is the 'correct' way, however it works quite well for me.
> >
> > The advantages are that your patch is always up to date with upstream - since
> > you're usually less than one day behind.
> >
> > The drawback is that you lose your changes with each --reset -- however when
> > you create a patch with git format-patch you have a copy of your changes
> > always at hand - and you can perhaps reapply them.
> >
> > Peter
> >
> >
> Agree, it will work well and yes you have all your patches on hand so
> can't see any problem with this you can always just re-apply if need be.
>
> 'Correct' I guess is what works well for you and I can't see why this
> approach won't work well, seems pretty logical and is the way I am going
> to use.
>
> Thanks for this info was exactly what I wanted!
In the end, I think you are *manually* rebasing your work on top of the
daily released linux-next.
I think most of the time, you can to it automatically with git rebase
after a git remote update instead of reset + pull.
>
> Joe
>
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Nicolas Palix
Tel: (+33) 1 44 27 87 25
Tel: (+33) 6 81 07 91 72
Web: http://www.diku.dk/~npalix/
--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
prev parent reply other threads:[~2010-07-06 8:28 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-05 20:43 Keeping up to date with the upstream Joe Eloff
2010-07-05 20:52 ` Peter Hüwe
2010-07-05 21:11 ` Joe Eloff
2010-07-05 21:37 ` Peter Hüwe
2010-07-05 21:44 ` Joe Eloff
2010-07-06 8:28 ` Nicolas Palix [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201007061029.00055.npalix@diku.dk \
--to=npalix@diku.dk \
--cc=kernel-janitors@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox