public inbox for kernel-janitors@vger.kernel.org
 help / color / mirror / Atom feed
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

      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