[U-Boot] Attn Maintainers: git advise needed (how to fix messed up repo)

[Graeme Russ]

Hi Mike,

On Tue, Nov 29, 2011 at 10:43 AM, Mike Frysinger <vapier at 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-x86@git.denx.de/u-boot-x86
>> >>> >> ...
>> >>> >> To ssh://gu-x86@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-x86@git.denx.de/u-boot-x86
> git checkout next
> git rebase master
> git push ssh://gu-x86@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-x86@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