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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
