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

[Mike Frysinger <vapier@gentoo.org>]

On Tuesday 29 November 2011 17:57:39 Graeme Russ wrote:
>  1) ${upstream}/master merges in multiple conflicting ${sub-repo}/master
>     and the order that they get pulled results in a conflict

when a merge is done and a conflict is thrown up, it's up to the guy doing the 
merge to resolve that conflict and commit the result.  this is considered 
"normal" in the git workflow.  just search the git log for "Conflicts:" to see 
this in action.

>  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

there will only be a conflict, if there's a conflict (i.e. two patches changing 
the same file in the same place).  simply having different changesets in the 
repos is normal git workflow.  this is why we have "merge commits" in the git 
log.  these show up all the time when Wolfgang merges branches.

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

there are merge commits and sometimes conflicts in those merges.  it depends on 
the conflict type as to what Wolfgang will do: tell you to rebase onto his 
master and thus it's your problem to resolve the conflict, or he'll fix it up 
locally.

> 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 keep them in a topic branch and ask Wolfgang to pull those, and i rewrite 
those branches since they're "development" ones

most common example with my repo i think is the "sf" branch where i merge spi 
flash related changes

> 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?

i pull Wolfgang's master, put my Blackfin patches on top, and then publish it 
and ask for a pull request.  i don't pull newer updates from Wolfgang until 
he's merged my changes.  or at least, i don't publish the updates.

> Lastly, is there any real difference between a sub-repo and a branch?

from git's pov, not really.  a sub-repo is just to keep things more cleanly 
separated and to grants ACLs on a simpler basis.  we could just as easily have 
all sub-repos be in Wolfgang's tree in namespaced branches:
	master
	x86/master
	blackfin/master
	arm/master
	arm/ti/master
	arm/tegra/master
	..........

but then things can get "noisy" as you see all the pushes/changes made by 
other people.  *shrug*.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20111129/4aa9052e/attachment.pgp>