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

[Graeme Russ]

Hi Andy, Mike,

Thanks for all your help. I've managed to clean-up the x86 repo, but I
still have a few lingering thoughts if you can spare a few more moments...

I understand why a published (i.e. pushed onto the denx server) branch
should never be altered and should, therefore, never require a forced push.

But I can think of two (probably the same) problematic scenarios:

 1) ${upstream}/master merges in multiple conflicting ${sub-repo}/master
    and the order that they get pulled results in a conflict
 2) ${sub-repo}/master has been published but not pulled before more
    patches have been added to ${upstream}/master - If ${sub-repo}/master
    does a fetch/pull of ${upstream}/master, there will be a conflict

Now ${upstream}/master is always the 'gold standard', so what does the
conflicted sub-repo dpo with the already published patches?

Mike, you were saying that you don't keep your ${sub-repo}/master sync'd
with ${upstream}/master - I understand how that works when nothing in
that you are responsible for ever changes in ${upstream}/master without
going through your ${sub-repo}/master, but what about when that is not the
case. For example, with some of the major architectural changes being made
to create more common code, how to you ensure the patches in your
${sub-repo}/master do not conflict?

I had a look at u-boot-blackfin and I noticed that there are non-blackfin
patches. u-boot-x86 also has the latest u-boot patches but there is no
merge commit in u-boot-x86 - So how do the u-boot patches get into
${sub-repo}/master without a merge?

Lastly, is there any real difference between a sub-repo and a branch? It
seems to me the principles of pull, merge, rebase etc are about the same
between the two.

Sorry if these questions are 'assumed knowledge' but I really don't want
to get x86 messed up again

Also, I know there are some good git tutorials out there (and I've read
a few) but I find it so much easier when referencing the U-Boot dev
cycle because a) it's what I'm working on and b) as an example, it seems
to be a good balance between 'fairly simple git workflow' and 'insanely
complicated git workflow'

Thanks and Regards,

Graeme