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

[Mike Frysinger]

On Tuesday 29 November 2011 18:48:08 Graeme Russ wrote:
> On Wed, Nov 30, 2011 at 10:35 AM, Mike Frysinger wrote:
> > On Tuesday 29 November 2011 17:57:39 Graeme Russ wrote:
> >> 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.
> 
> At this point, how do you make the merge 'conflict free' without re-writing
> the sub-repo?

you can't.  but the counter point is: why is this a problem ?  if one patch is 
tweaking the style, but other is deleting the code block altogether, you get a 
conflict, but it's easy to resolve and commit the result.  not the best 
example, but many conflicts are trivial to resolve.  this is considered part of 
the git workflow as well -- people working in parallel on the same tree are 
bound to touch the same code.  rather than rebasing, do a merge, get a 
conflict, and then fix the conflict and commit it as part of the merge commit.

it's happened at least 65 times since we switched to git:
$ git log | grep -c Conflicts:
65

> >> 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.
> 
> So you pull u-boot/master straight into u-boot-blackfin/master? From what
> I gather, this is the same as fetch/merge. So if you merge branch 'A' into
> branch 'B' you get a merge commit, and if you then merge 'B' into 'A' there
> is no second merge commit because the merge is already done?

correct.  so when Wolfgang pulls my branch, he either fast forwards because he 
hasn't done any new work, or he gets a merge commit.  in either case, when i 
pull his branch, mine is always a fast forward (since his tree has everything 
mine does already).
-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/98f8c0c5/attachment.pgp>