From: Joe Eloff <kagen101@gmail.com>
To: kernel-janitors@vger.kernel.org
Subject: Re: Keeping up to date with the upstream
Date: Mon, 05 Jul 2010 21:11:22 +0000 [thread overview]
Message-ID: <1278364282.5396.50.camel@dermezel> (raw)
In-Reply-To: <1278362590.5396.35.camel@dermezel>
On Mon, 2010-07-05 at 22:52 +0200, Peter Hüwe wrote:
> Am Montag 05 Juli 2010 22:43:10 schrieb Joe Eloff:
> > Hi
> >
> > Just need clarification on this procedure:
> >
> > What to do when git fetch origin tells you origin/master has diverged from
> > your local master and you are working on a branch making patches?
> >
> > A link or search words will be fine will do reading myself.
>
>
> Hi Joe,
>
> quite often a simple
> git merge master
> should do the job
>
> git fetch + git merge = git pull
> --> So you should perhaps try git pull instead.
>
> However on trees that get rebased quite often (e.g. linux-next) the merge may
> fail.
>
> With linux next I simply do something like
> git fetch
> git reset --hard origin
> on the master branch and not using any branches at all.
>
> But this is only a good approach if you start working on a patch - otherwise
> you'd lose your changes.
> But as a janitor you usually don't do large (multiple workday) patches so this
> might work for you too.
> git fetch
> git reset --hard origin
> #start working
> #when finished
> git commit -a
> git format-patch -s origin
>
> --> Your (hopefully) ready to send patch is created.
>
> Works fine for me, for janitorial tasks.
>
> Thanks,
> Peter
>
Hi Peter,
Thanks for the reply, use git as primary repo system for all projects I
work on so am pretty familiar with what the commands do, was just not
sure in this environment and just wanted to make sure I don't mess up.
I saw there where conflicts when I tried to merge origin/master so that
was not going to work like you said working on linux-next that gets
rebased quite often that might not work.
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.
Gotchya,
Regards,
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
next prev parent reply other threads:[~2010-07-05 21:11 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 [this message]
2010-07-05 21:37 ` Peter Hüwe
2010-07-05 21:44 ` Joe Eloff
2010-07-06 8:28 ` Nicolas Palix
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=1278364282.5396.50.camel@dermezel \
--to=kagen101@gmail.com \
--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