Hi Mike, On Tue, Nov 29, 2011 at 10:43 AM, Mike Frysinger <vap...@gentoo.org> wrote: > On Monday 28 November 2011 18:20:51 Graeme Russ wrote: >> On Tue, Nov 29, 2011 at 10:16 AM, Andy Fleming wrote: >> > On Mon, Nov 28, 2011 at 5:13 PM, Mike Frysinger wrote: >> >> On Monday 28 November 2011 18:05:00 Graeme Russ wrote: >> >>> On Tue, Nov 29, 2011 at 10:02 AM, Mike Frysinger wrote: >> >>> > On Monday 28 November 2011 17:31:19 Graeme Russ wrote: >> >>> >> $ git fetch u-boot >> >>> >> ... >> >>> >> $ git rebase u-boot/master >> >>> >> ... >> >>> >> $ git push ssh://gu-...@git.denx.de/u-boot-x86 >> >>> >> ... >> >>> >> To ssh://gu-...@git.denx.de/u-boot-x86 >> >>> >> ! [rejected] master -> master (non-fast-forward) >> >>> > >> >>> > well, you did a rebase, so this is kind of par for the course. use >> >>> > --force to rewrite the published branch. >> >>> >> >>> So how do you keep the sub-repo up-to-date with u-boot/master without >> >>> doing forced pushes? >> >> >> >> you don't :). the way *i* work is to keep my changes in my own branch >> >> that i rewrite, and then once i want to send that to Wolfgang, i >> >> publish the updated master branch for him to pull from. >> >> >> >> i think the u-boot wiki has a "suggested maintainer workflow", but i >> >> haven't looked too hard at that as i like (logically) how i do things >> >> now. >> > >> > Yes, I only push up changes that I don't intend will ever be changed. >> >> Well, that is my intent too :) > > you can never rebase+publish that branch then > >> > Unless I forget. >> > >> > If your tree contains changes that aren't yet in Wolfgang's tree, but >> > *are* published in your upstream tree, then you can try: >> > >> > git merge u-boot/master. >> >> So is that in lieu of rebase? > > yes, if you want to get updates from mainline before asking Wolfgang to do a > pull request on your branch > > note: you don't have to publish the merge/rebasing work. let's say you have 3 > patches in your x86 master (published). locally, you get Wolfgang's updated > master, verify things still work, and then send a pull request for the already > published branch (not for your local work which includes a merge commit). > once Wolfgang pulls & pushes that update, you can fetch Wolfgang's master and > then rebase on top of that. in this case, the only thing being thrown away is > your local merge commits because Wolfgang included your other changes. > > this can be a bit confusing as it delves deeply into distributed scm
You are correct - I am totally confused by all of this :( > subtleties, so if you want, i can clarify points from above ... Yes, that would be nice :) I think a few concrete examples with git commands to illustrate would be helpful. What I am thinking of doing is something along the lines of: > cd Source/U-Boot/x86 (my local version of the u-boot-x86 repo) > git fetch u-boot (as per the 'new' methodology of not having a seperate u-boot branch) > git checkout master > git rebase u-boot/master > git push ssh://gu-...@git.denx.de/u-boot-x86 > git checkout next > git rebase master > git push ssh://gu-...@git.denx.de/u-boot-x86 Do the above periodically so anyone working off u-boot-x86 can keep up-to-date And when I'm happy with a patchwork patch, do the above and then: > git am <patches downloaded from patchwork only> > git push ssh://gu-...@git.denx.de/u-boot-x86 My local u-boot-x86/master branch will only ever contains patches that are ready to be pulled by Wolfgang And for my day-to-day development: > git checkout dev > git rebase master > stg new/pop/push/delete/squash etc... My local u-boot-x86/dev branch has lots of rubbish - usually an stg stack a mile long of various experimental stuff - I actually have multiple dev branches. I like to pull the patches ready for upstreaming into those branches first just to see what I am up against when the new patches go live. But this seems to cause the 'must force the push' problem... Regards, Graeme _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
