Keeping up to date with the upstream

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.

Am Montag 05 Juli 2010 22:43:10 schrieb Joe Eloff:

Quoted 8 lines

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

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.

Am Montag 05 Juli 2010 23:11:22 schrieben Sie:

Quoted 9 lines

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

Quoted 15 lines · Peter Hüwe

Am Montag 05 Juli 2010 23:11:22 schrieben Sie:

Quoted 9 lines

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.

Quoted 10 lines

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html