Keeping up to date with the upstream

Keeping up to date with the upstream

[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.

Regards,

Joe

Re: Keeping up to date with the upstream

[Peter Hüwe]

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

Re: Keeping up to date with the upstream

[Joe Eloff]

 
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

Re: Keeping up to date with the upstream

[Peter Hüwe]

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

Re: Keeping up to date with the upstream

[Joe Eloff]

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!

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

Re: Keeping up to date with the upstream

[Nicolas Palix]

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